Extreme Programming Contents Page

Extreme Programming

If you are thinking about implementing extreme programming, read the references mentioned in this document in order to fully understand the implementation. This document simply gives a summary overview of extreme programming so the reader can decide it they are interested pursuing extreme programming further.

Extreme programming (XP) is about project management and programming methodologies that are designed to enhance production. Extreme programming has some similarities with the Rational Unified Process (RUP) and some ways could be considered a very abbreviated version of the RUP with modifications. Also some extreme programming methodologies can be applied without applying all extreme programming methods. One such example is pair programming.

RUP/UML and XP Differences

However, although XP has some similarities with the Rational Unified Process (RUP), and XP methods can be applied elsewhere, don't be fooled. Although some XP methods will work well by themselves, XP has many differences and many of the methods behind it are interdependent. This means that if some methods of XP are left out, the system may not work.

Another important difference between XP and RUP/UML is that XP does not use drawings to enhance the analysis and design process. It does not plan for change as does RUP/UML. Based on the methods used in XP, the code is expected to be of a higher quality. Also it relies heavily on refactoring the code to make changes as additional features or changes are required. Refactoring code is the process of changing code to improve its structure as it evolves. Generally XP is introducing constant course corrections to the project, but RUP/UML is planned ahead to more easily accomodate changes.

XP Project Application

Some experts say that extreme programming works best with small to medium size projects and it is best to use Unified Modeling Language (UML) and the Rational Unified Process for running larger software projects. It is said that extreme programming works best for high risk projects.

Brief XP Planning Description

Basically, when an extreme programming project is started, user stories (similar to use cases which are called "metaphors") are written on an index card as a short story. The customer writes the stories and they should be focused on user needs. The business and technical staff are placed in the same room. The business people must rate each story card as follows:

  1. Absolutely must have it.
  2. I need it but I could barely live without it.
  3. If you twist my arm, I don't really need it.

The technical people rate each story card as requiring one, two, or three man weeks in uninterrupted time for one programmer, ignoring pair programming. If a story requires more than three man weeks, it is broken down further. The technical people rate the risk of each story as low, medium, and high. Once done, the stories may placed in order and are worked on in that order. This is known as "the Planning Game".

On a practical level, the order of the stories should be from most essential and highest risk to least required and lowest risk. However this may not always be the case. The customer should determine the order of the stories in conjunction with the interdependence of the stories (functionality) required to make a working and testable system. Therefore the technical staff would have some input here but the customer has more priority.

Planning may be done several times over the life of the project as requirements change or new issues are discovered. An overall schedule and budget may be estimated by figuring the estimated time for the work factored with the project velocity. As feedback is gained during the project, the estimates may need to be revised or remove some project scope (Of course you could finish ahead of schedule).

Control Variables

XP utilizes four project control variables:

XP Values

XP Principles

XP Principle Interdependencies

  1. Group ownership depends on frequent testing, continuous integration, coding standards, and pair programming.
  2. Refactoring depends on coding standards, group ownership, continuous integration, pair programming, and simple design.
  3. Simple design depends on communication, refactoring, and pair programming.
  4. Testing depends on simple design, and pair programming.
  5. Pair programming depends on correct working hours, coding standards, simple design, and testing.

There are other dependencies, but these illustrate the point.

Other XP strategies/values

Tracking Progress

One team member is designated as the project tracker. Twice per week, the tracker asks each member for their task:

Based on this, you can tell how the team is progressing or if there are any trouble areas.

As iterations are completed project velocity can be measured. Project velocity is the ratio between estimated time and real calender time. A chart of the project velocity is posted by the manager showing the medium velocity (Metric). Too many metrics become meaningless.


Iterations are generally two to three weeks long with releases being every one to three months.

Management and Staff Relationships