| How do you plan the overall shape of a project in XP? This article summarizes planning with little reference to the programming aspects of XP. |
Vocabulary
People:
- Team: the customers, programmers, and managers who are jointly working on the system.
- Customer: the person or group defining the need for the system and what it does.
- Programmer: the person or group that estimates and implements the system.
Processes:
- Exploration: part of the release cycle: when customers create stories, and programmers estimate them.
- Iteration: part of the release cycle: a fixed-length time for implementation of stories. An iteration is time-boxed: if all stories can’t be completed, stories are dropped rather than the iteration extended.
- Release: delivery of system (usually to end users).
Artifacts:
- Story: a feature or capability of the system that a customer values.
- Estimate: the cost (usually time) to implement a story. There have historically been two ways of doing estimates in XP: relative (a story is estimated as costing 1 to 3 “story points”), or absolute (so many hours for a pair).
- Release Plan: a flexible, overall plan that tells which stories are expected in which iteration, for a whole release.
- Iteration Plan: a small plan that tells which features are expected in the current iteration.
Capsule Summary
In XP, planning at implementation can take place at any time, but an XP project usually has different emphases at different times.
Exploration: The team learns about the problem and the technology options for a solution. The programmers estimate the cost of each story. Exploration typically lasts one to four weeks. Result: All important stories are understood (reasonably well) and estimated (in story points).
Release Planning: The programmers tell how many story points per iteration they expect to deliver. The customer plans which stories will be in the release, and in approximately what order they should be implemented. Result: A release plan.
Iterations: The team implements another group of stories, whichever ones the customer thinks are the most important at that time (and whose cost lets them fit into the iteration). Iterations have a standard size, typically one to three weeks. Result: Working system that the customer can test.
Release: The team readies the system for release to a broader group. Releases are typically one to three months apart. Result: System delivered to end users.
Implications
From even the small description above, we can see several implications:
- All the cycles are very short. The whole release cycle occurs in weeks to months.
- The release plan is created approximately a quarter of the way through the release cycle.
- The plan can be revised (by the customer!) at any time. At the start of each iteration, the customer decides which stories are most important at that time.
- This flexibility places a burden on the programmers: they must be prepared to implement any feature next. XP uses specific programming techniques to make this possible in the software realm, and teams can use conditional estimates for special cases (“3 for the first one and 1 for each one after that”).
The Estimates
The programmers work with the customers to make sure both parties agree on the meaning of a story. Then, the programmers give an estimate representing how much effort they believe is involved to deliver that feature.
Some teams use relative estimates. A common style is 1 to 3 points; anything bigger than 3, the customer is asked to split the story into smaller stories.) The programmers typically think of a 1 as being, “If this were all I was doing, I could do it in 1 week.”
Why the relative estimates instead of absolute estimates (e.g., 12 days)? Because people tend to better at relative sizes (“this is about the same work as that”), and they tend to be better at thinking in terms of working time than in estimating their overhead.
Other teams use absolute estimates. (This is the approach Kent Beck is currently recommending.) This is typically done in pair-hours (the cost for two people working together for one hour).
What if we later find out an estimate is wrong? The team can update their estimates at any time as they learn more. (And yes – if things suddenly get expensive or cheap, it can have a big impact on the release, and the customer may re-assess the overall plan.)
The Release Plan
Once every story has an estimate, the programmers declare how much much capacity they think they will average per iteration (“the velocity”). (A reasonable, conservative guess is “1/4 pair-hour per programmer per week.”)
The customer creates the release plan as a list of features in priority order, grouped into iterations according to the estimate and the velocity. The customer can split any story that doesn’t quite fit (and have the programmers estimate the new stories).
For example, assuming a declared velocity of 40 hours per iteration and a team planning to do 3 iterations:
| Iteration | Stories |
|---|---|
| Iteration 1 | Text screen – 10 hours Simple query – 30 hours |
| Iteration 2 | Boolean query – 20 hours Simple screen – 20 hours |
| Iteration 3 | Printing – 30 hours Distribution – 10 hours |
The customer can decide whether the goal for the release is a certain list of features or a certain release date. (Iterations have a fixed duration, but the overall release may or may not be time-boxed.) This plan can (and often should) after each iteration, as the team learns more.
The First Iteration
XP suggests a special goal for the first iteration: it needs to provide a minimal, end-to-end solution involving every major component. (Many components will be present in only skeletal form.)
In the example above, the team might split “Simple query” and “Printing,” and find a way to fit super-simple versions of each into the first iteration.
The first iteration provides a skeleton for the rest of the implementation, and it helps address high risks in the project. The team is free to completely change the structure around later, but the first iteration provides a starting point.
Other Iterations
Use however many story points the team finished in the last iteration as the estimate for how many points will be done in the next iteration. (This is called the “Yesterday’s Weather” rule: the best predictor for today’s weather was yesterday’s weather.)
For example:
| Expected Velocity | Actual Velocity | Accumulated Points |
Projected in 3 Iterations |
|
|---|---|---|---|---|
| Iteration 1 | 40 | 20 | 20 | 60 |
| Iteration 2 | 20 | 40 | 60 | 100 |
| Iteration 3 | 40 | 40 | 100 | 100 |
The velocity may bounce around some at first, but it usually stabilizes.
Notice that in the release plan we originally expected to get 120 points in 3 iterations, but we only completed 100 points worth. And at the end of the first iteration, it looked even bleaker. This is a place where the customer’s involvement is crucial: the customer can split or simplify stories, move the end date, ask for more people, cancel the project, or do whatever they need to do given the status of the project.
How does a team increase its velocity? If a team feels they’re on track to finish early, they’ll ask for more work in the middle of the iteration.
Iteration Planning
Going a level deeper, XP uses a similar process for deciding what to do in an iteration.
- The customer selects stories for the iteration. (This is subject to “Yesterday’s Weather” – scheduling only as many hours as were completed in the previous iteration.)
- The team discusses each selected story, and brainstorms tasks that would implement them.
- Team members accept and estimate tasks.
- The team adjusts and balances the tasks to make sure they fit into the iteration.
The tasks for an iteration are in the development team’s purview. It’s typical for the customer to be present during this planning, as there will often be questions. These are the two most common approaches to task estimation:
- No estimates on tasks: the team eyeballs the tasks to make sure none look too large (e.g., not bigger than half a day’s work)
- Hour-based absolute estimates: the number of pair-hours a task is expected to take. Some teams try to estimate individual programmers’ velocities; more common is to use an estimate for the team as a whole.
The iteration planning is usually done the first morning of an iteration.
The iteration plan will often change during an iteration as a team learns about tasks they missed, or come up with a better or different way to do things.
What’s Interesting About XP’s Planning Processes?
- Extremely short cycles.
- Use of conversations and tests about stories rather than documents.
- Use of estimates, velocity, and fixed-length iterations.
- “Yesterday’s Weather” rule adjusting estimates every couple weeks.
- First iteration as a backbone for the implementation and a driver of risk identification.
- Commitment to flexibility, e.g., minimizing dependencies so stories can be implemented in arbitrary order.
Resources
- Planning Extreme Programming by Kent Beck and Martin Fowler. A full explanation of XP-style planning.
- Extreme Programming Explained: Embrace Change, 2/e, by Kent Beck and Cynthia Andres. An introduction to XP.
- “Story Time: Release Planning” (chapter 7 of Extreme Programming Explored, by Bill Wake.) Discussion of planning as a game, and more on the customer’s role.
- Extreme Programming Installed, by Ron Jeffries et al. Overview of XP (including planning) from the original XP team.
[Written Nov. 5, 2001. Updated Feb. 27, 2002 due to feedback from Kurt Keutzer and Ivan Tomek. Minor revisions May 27, 2006.]