Topics

• XP Planning Overview
• Iterations
• User Stories
• Release Planning
• Iteration Planning
• Task Planning
• Recovery
• Feedback
• Acceptance Tests
• How do we create budgets for the first iteration and release?
• How do changes in the team affect velocity?

XP Planning Overview

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 outcome.

Iterations

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.

User Stories

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.

Release Planning

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.

Iteration Planning

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.

Task Planning

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.

Recovery

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 remove some.

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.

Feedback

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 previous release.

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.

Acceptance Tests

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.

How do we create budgets for the first iteration and release?

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.

How do changes in the team affect 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.