In an XP project, requirements exist in the form of "stories" that are written by the customer. Each story briefly describes a single aspect of functionality (a feature) that is testable. The programmers estimate the relative amount of work required for each story (say, between 1 and 5 "foot-pounds"). The customers estimate the priority of each story compared to the others, assigning it a value (say, between 1 and 5 "dollars"). Using these estimates for each requirement, we can plan the scope of the two periods of an XP project: releases and iterations.

A release typically takes between 2 and 6 months to complete, and its scope is determined by business priorities. Using the cost and value of each story, the customer sketches out the scope of the next release, and the order in which stories should be done. This set of stories is then divided among iterations.

An iteration typically lasts between 1 and 3 weeks. In any case, it has a fixed duration for a project. Each iteration delivers the next small batch of features in the release, in priority order. Throughout the project, we always work on the remaining features with the highest priority.

At the beginning of each iteration the development team sits down and divides the stories scheduled for that iteration into discrete tasks. These tasks are then estimated. Then programmers sign up for a selection of tasks that they think they can accomplish in this iteration (in pairs, as described in pair programming).

At any given time, the plan for the current or next iteration is fairly solid, and the plan for the one after that is a rough sketch. Programmers know how much work they got done during the previous iteration and use that information to estimate the amount they will accomplish in the next iteration. If they signed up for too much in the current iteration, they try to get other programmers with free time to take up the slack, or they defer stories to the next iteration. If they find themselves out of stories before the end of the current iteration, they try to help other programmers, or they grab stories planned for the next iteration.

As a project progresses, estimates get more accurate. The estimates for the first iteration might be off, but the estimates for the fourth or fifth iteration should be quite accurate. And this is how XP teams converge on accurate projections for an entire project: by getting more accurate in their estimations of the work each requirement needs, and the work that can be done per iteration.

Imagine again that we have a scale of requirements value that runs from $1 to $5, and a scale of work for a requirement that goes from 1 foot-pound to 5 foot-pounds. Let's say our team has completed 6 iterations, and therefore has a solid idea what the team velocity is. We therefore know how many foot-pounds of work the team can finish by the deadline. This is our work budget. At any given time in the project, there is a list that specifies the remaining requirements to be done before the end of the project. This is what we have decided to "buy" with our budget.

But in the real business world, legitimate requirements changes can occur right in the middle of your project. The project must change course, or risk substantially reducing its ROI. In an XP project, this is typically not a problem. We can substitute high-priority features for lower-priority ones, as long as the work budget remains constant.

One day toward the end of iteration 7, Bob the Product Manager goes to Rick the Development Manager and says "Rick, we have a new $5 requirement we need you to estimate." Rick says "Sure thing, Bob. I can have you that for you within a couple of days." The next day Rick delivers to Bob the bad news that the $5 feature is also a 5-foot-pound feature. But this not really a problem. "Bob, we still have 7 iterations planned. As soon as you remove 5 foot-pounds from the current requirements budget, we can plan working on your new feature for the next iteration." And Rick does exactly that: he removes a 2-foot-pound feature and a 3 foot-pound feature from the current list of features to be completed by the release date, and substitutes the new $5, 5-foot-pound feature.

This is not an exceptional event in an XP project, but a typical one. New requirements arise all the time, and their value and cost are compared to the remaining requirements in the budget. The list of outstanding requirements changes. The plan for the release and for the next iteration changes. All of it is orderly and straightforward, without threats, recrimination, screaming, backstabbing, or firings. And at the end of the project, the customer has gotten more than what they asked for at first: they have gotten what they really wanted and needed, in order to get the highest and fastest ROI on the project.

[Next Practice]