An XP project is broken down into a set of two-week iterations. Each iteration follows the next in a linear sequence.
Executable code that passes unit tests and acceptance tests is the core deliverable beginning with the first iteration.
Planning an XP project is a continuous activity. There is no master plan that is decided upon at the start of the
project and that is followed until the end. An XP project is planned in detail, one iteration at a time. The plan for
an iteration is created at the beginning of that iteration. The plan is then checked and adjusted continuously
throughout the iteration.
Iterations are grouped into larger milestones called releases. A typical release spans two to three months. At the
beginning, the release plan is created. This is a very rough plan that tentatively describes the features that the
project team believes can and should be implemented during that time. The release plan is continuously updated as each
iteration within the release provides more data.
The overriding principle of XP planning is feedback. Every iteration provides data about the velocity of the team. That
data is used to continuously calibrate the plan. Measuring the results of each iteration generates a continuous stream
of data. The team and its managers use that data to make decisions and take actions that will improve the project
An iteration is simply a span of time in which the team implements a set of features. In an XP project, this time is
typically two weeks and should never be longer than four. The team should decide how long its iterations should be and
then stick to that time. It is not wise to continuously change the duration of the iterations because that makes
determination of a team's velocity more complicated.
When an iteration is over, it is over, irrespective of how much the iteration accomplished. It is never wise to extend
an iteration in order to provide more time to finish the planned deliverables. The ability to plan an XP project
depends strongly on fixed-length iterations of consistent duration and ruthless termination of each iteration
irrespective of whether the planned tasks are complete to allow the velocity to be measured.
The content or scope of an XP project is described in user stories. User stories are very simple descriptions of the
features to be developed. Each story is typically written on a single index card and contains virtually no detail. The
card contains little more than the name of the feature.
Stories are the tokens of planning. When we create a release plan or an iteration plan, we select the stories we want
in that release or iteration and schedule them. Once a story is scheduled for an iteration, two things must happen in
that iteration. First, the details of the story must be fleshed out, resulting in the creation of appropriate
acceptance tests. Second, the story must be implemented so that it passes those acceptance tests.
In order to choose which stories to schedule for an iteration, we need to know two things: how important is the story
and how long will the story take to implement. The first comes from the judgment of the customers/stakeholders, and the
second comes from the judgment of the developers.
Developers estimate the stories. The estimate for a user story should neither be too big nor too small. Those that are
too big should be split into multiple stories, and those that are too small should be merged. A good guideline is to
keep the size of a user story between two days and a week of team effort. The customer/stakeholders and the developers
will negotiate over the stories, splitting and merging as necessary, until they are appropriately sized.
Estimates are written on the story cards as numbers. We refer to these numbers as story points. It doesn't matter what
units were originally used to create the estimates. It might have been man-days or man weeks or something else. Once
the estimates are made, we forget the units and simply refer to them as story points.
The customer/stakeholders know what features they want completed for the next release. The developers know how much
they can get done in the next release. The developers give the customer/stakeholders a budget for the release based
upon how much the developers got done in the previous release. If the developers finished 720 story points in the last
release, then it is safe to say that they'll finish about 720 in this release.
The customer/stakeholders choose stories that add up to this number. They choose the stories that are most critical and
have the most business value. They lay them out in roughly the order in which they'd like to see them implemented. This
selection and ordering of the stories becomes the release plan.
Any stakeholder can look at the release plan and see about when a particular feature will be implemented. They know
that, if the feature is listed early, then it is likely to be completed. If a story is listed late in the plan, then
the risk is higher. The release plan is not static. Any time priorities change, the customer/stakeholders can change
the plan by reordering stories, adding new stories, removing existing stories, and so on. Thus, the release plan is
always changing in response to the changing business.
At the beginning of each iteration, we take a half day to plan that iteration. The developers supply the
customer/stakeholders with a budget for the iteration based upon what they finished in the last iteration. If they got
68 story points done in the last iteration, then it is safe to plan for 68 in this iteration.
The customer/stakeholders select the stories from the release plan that they feel are most important for this
iteration. The sum of the selected story points cannot exceed the budget given by the developers.
Though the customer/stakeholders can suggest an ordering for the stories in an iteration, the developers are not bound
to that ordering. The developers are free to rearrange the stories within the iteration in any manner that makes sense.
Once the iteration has begun, the customer/stakeholders cannot make arbitrary changes to the stories in that iteration.
Any change has to be carefully negotiated with the developers. If the customer/stakeholders want to remove a story and
replace it with another, they must check with the developers to see if that will fit in the iteration. If the
developers agree, then the change can be made. If the developers do not agree then the customer/stakeholder may decide
to wait until the next iteration or may decide to completely abort the current iteration and plan a new iteration.
Once the stories have been selected for the iteration, then the developers break the stories down into programming
tasks. The tasks are recorded on a whiteboard or a flip chart.
Tasks are simple units of work that accomplish a particular goal within a story. One task might be to set up the
database schema for a story. Another might be to create the HTML pages for a story. Still another task might be to
write a servlet that checks passwords. A task should be on the order of a man-day of effort.
The breakdown of stories into tasks is a design activity. The developers consider how the stories will be developed and
whether or not there are any design options that allow the stories to share tasks.
Once the list of tasks is complete, the developers take turns signing up for the tasks. Each developer puts his or her
initials next to a task and then estimates that task. The estimate is typically in hours.
Each developer has a budget of hours that he keeps in the back of his head. This budget represents the number of hours
he believes he will have for the development of his tasks in this iteration. Each time a developer signs up for a task,
he deducts his estimate from that budget. When a developer's budget goes to zero, he stops signing up for tasks.
Ideally, at the end of sign up, all the tasks would have initials, and every developer's budget would be at zero. But
this is seldom the case. There are two much more likely scenarios:
Everybody's budget is at zero, and there are tasks left. In this case, the developers need to work together to find
a better division of tasks. If a GUI guy signed up for a database task just to get some new experience, then
perhaps he should swap with someone who could do that task more quickly. If after such trading there are still
tasks left over, then the team has to ask the customer/stakeholder to remove some stories or tasks.
The tasks are all signed up, but some people still have budget left. In this case, the team needs to ask the
customer/stakeholders to give them a few more stories.
On the day that marks the halfway point of the iteration, the team has another short meeting. Half the tasks should be
complete. More importantly, half the stories should be complete. More precisely, a set of stories whose points add up
to half the iteration budget should be complete. The nightmare we are trying to avoid is that the iteration ends with
all the stories 95% complete. We'd rather that 95% of the stories be complete.
If half the stories are not complete, then the team asks the customer to remove some stories from the iteration. This
same kind of check is made towards the end of the iteration. The team assesses how much they have working and how much
is left. If it appears that they may not complete all the promised stories, then they ask the customer/stakeholders to
By the same token, if more than half the stories are complete by the midpoint, the developers ask the
customer/stakeholder for more work. Likewise, as the iteration gets close to the end, any idle developers should help
others complete their tasks. If it appears that all tasks will be completed early, the developers should ask the
customer/stakeholders for more stories.
The number of story points completed in the previous iteration is the team's current velocity. This velocity is used as
the budget for the next iteration. Thus we only commit to doing what we know we did in the last iteration.
The same is true for releases. When we plan the next release, we use the number of story points we finished in the
Individual developers use the same technique for their task budgets. If they got 22 hours worth of tasks finished in
the last iteration, they should only sign up for 22 hours of tasks this time.
After the iteration-planning meeting is over, the customer/stakeholders must provide the developers with acceptance
tests for the stories that were selected for the iteration. Typically, these tests will be created with the help of the
Q/A or testing groups. These tests specify exactly to the developers what the stories being implemented must do, so
they must be given to the developers as early as possible.
Some XP teams manage to write their acceptance tests an iteration early. The Q/A or testing group works with the
customer/stakeholders during the current iteration to determine which stories are most likely to be selected for the
next iteration. Together, they define the set of acceptance tests that will be given to the developers during the next
iteration planning meeting. By planning ahead like this, the developers can have the acceptance tests for an
iteration's stories immediately.
If you have history from other projects, then make use of that. Otherwise, you have to guess. A good way to guess is to
spend a day or two trying to implement one or two stories. This should give you an inkling of your velocity.
If the change is small, then it's probably best to allow the velocity to change by itself. If you got 52 story points
done last iteration, but this iteration you have a new team member, it's probably best to keep your velocity at 52 and
commit do doing just 52 story points in the next iteration. At the end of that iteration, you may find that you've done
a little more than 52, and you can adjust your velocity accordingly.
On the other hand, if 30% of the team is going on vacation for the next iteration, then it's probably wise to reduce
your velocity accordingly.