Plans are useless, but planning is indispensable.

-- Dwight D. Eisenhower

An iteration adds function to a system without breaking it. The new features are delivered to the customer in a complete software distribution. This way the customer can try out the story implementations, and the programmers can get feedback on the system every few weeks, before the entire release is implemented.

While release planning sets the pace for the customer, iterations are the heartbeat of the system's implementation. By distributing the software on a fixed schedule, typically from one to three weeks, the programmers stay focused on delivering complete stories. This avoids the situation where the system remains "95% done" until the entire release has been implemented. XP programmers complete the most important story first before moving on to the next one.

This chapter covers dividing stories into tasks during the iteration planning meeting, estimating tasks, grouping tasks into iterations, and tracking team and individual velocity to schedule the next iteration's work.

Tasks

A task is the basic unit of work of an iteration. The stories are broken down into a list of tasks during the iteration planning meeting. For example, here are the tasks for two of the stories from Release Planning:

PaymentsInFiscalYear

• Mockup report.

• Implement year at a glance widget.

• Implement data model and report.

• Acceptance test: validate payments in months for members.

CloseChase

• Compare rates and services at local banks.

• Open new account.

• Move automatic payments (FedEx, EarthLink)

• After last check clears, transfer remaining funds.

• Acceptance test: verify account is closed and automatic payments working.

For reasons of simplicity, I write the tasks directly on the bottom of the story cards. This keeps the motivation for the work (the story) and the list of work items on one piece of paper. This helps me stay focused on the trees without getting lost in the forest.

Alternatively, you might create separate task cards, one for each work item. This allows you to divide up the work for an individual story among several programmers. If you tend towards larger, multi-week stories, task cards are probably the way to go.

The Meeting

Iteration planning involves the entire team. Somebody reads the stories aloud, and everybody contributes to identifying the tasks, which are written on whiteboards or flip charts for all to see. Another person writes the tasks down on the cards once everyone agrees they are correct.

The meeting is a time for group design discussions. It isn't always obvious what tasks are required to implement a story. While ad hoc design discussions pop up during programming, iteration planning is a time for the whole team to discuss the system's implementation. You might realize that a global refactorings need scheduling. This may add dependencies and possibly a new story for the customer to prioritize.

After all the tasks are listed on the board, people commit to implementing them. Individuals take the cards and estimate the tasks they are planning to implement. As with stories, estimate in ideal programming days. Everybody's ideal timescale is different, don't expect the task and story estimates to add up.

If a task is difficult to estimate, ask for help. Others may have a better feeling for the problem and/or implementation. Sometimes a task is too complex, and you'll realize as a group that the risk factors were underestimated. Restructure the task list for this story. If you think this story's estimate is way off, discuss it with the person responsible for the story estimate. It may need to be changed, and the customer should be informed of the unforeseen considerations and the new estimate.

Get Me a Bucket

In plan-driven methodologies, the amount of work that goes into software distribution is dictated by the plan. The schedule is extended as you experience the actual implementation time for the work items. A software distribution only comes out when the entire release is complete. XP takes another view. Software distributions flow out from the team in fixed time iterations, much like water flowing through a water wheel.

The buckets on a water wheel[1] are a fixed size, too, and only one bucket is necessary to get the water wheel turning. If the bucket is too large, the wheel won't turn for awhile, and the water will flow in fits and starts. Tiny buckets don't supply enough energy to move the wheel at all. There's a reasonable range of sizes for efficient transfer of potential to kinetic energy. Experience suggests that the most efficient range for XP iterations is one to three weeks. Each team must decide, however, what works best.

Velocity

The rate at which the water flows through a water wheel is measured in cubic feet or meters per second. The implementation flow rate in XP is called velocity, and is the ratio of estimated ideal days to real implementation days. Since the number of real days is fixed per iteration, we simply keep track of the sum of the estimated ideal days for each iteration. The ideal time budget for the next iteration is the velocity of the iteration just completed.

Our goal in XP iteration planning is to predictably fill an iteration with exactly the right number of stories. This reduces planning time to a minimum, and keeps the software process flowing smoothly and reliably, just like an efficiently designed water wheel.

Velocity is a relative measure, however. You can only compare like estimates. The team's velocity is the sum of estimates for completed stories per iteration. Likewise, your individual velocity is measured in your own estimation timescale, the sum of your task estimates completed per iteration. You can't compare the velocities of different individuals, and it doesn't matter if the sum of task estimates doesn't add up to their story estimate. It's like comparing water wheel flow rates with the rate at which people flow on an escalator. The denominators are the same, but the numerators are different.

Your velocity should converge after the first few iterations. If it doesn't, something's wrong, and in Tracking, I discuss what to do about it. The starting budget for the first iteration is a guess. It's likely to be way off. At first, it's reasonable to assume the ratio of ideal days to real days is 1:1. Scheduling the first iteration is just the beginning. You'll find you and your team's natural velocity converges rapidly no matter what the starting point is.

Watch Your Speed

Velocity is a self-governing speed limit. The team limits the sum of its story estimates to the velocity of the prior iteration. The sum of your task estimates should not exceed your individual velocity. That is, you should sign up for the same amount of estimated work that you completed last iteration.

If you signed up for too many tasks, look for somebody with excess capacity. Pick a simpler story if no one volunteers. We avoid splitting stories across iterations, because it complicates tracking. All stories will be implemented by release end, so you'll be able to pick the story you dropped next iteration, if it still interests you.

Customer Priorities

The priority on the story card expresses the customer's expectation of business value. Programmers work on the highest priority stories in each iteration. In XP, we deliver as much business value as early as possible in the release.

There's no guarantee all stories can be implemented. The best way for the customer to ensure a particular feature is added is to limit the scope of the release. If the programmers get done early, you can add stories in a mid-release planning game followed by an iteration planning meeting. And, if you run out of work before the end of the iteration, grab the highest priority story card, estimate the tasks, and implement them. This is how you increase your individual velocity.

The Beat Goes on

From the first iteration to the last, an XP team cranks out a steady stream of software distributions. Programming, like many other creative professions, needs a regular beat.[2] It's all too easy to get distracted by an interesting problem. Regular, high frequency deadlines help people to stay on track.

Every team has to find its own rhythm. Weekly iterations work well in my experience, and they dovetail nicely with the 40-hour week practice of XP. At the end of the week, we go home with a clean plate, and come back with a fresh mind for the next iteration.

Whether you deliver every week or every few weeks, the goal is to keep the software water wheel flowing to the customer. She sees steady progress, and programmers get high frequency feedback about the quality of the system.

Footnotes

1. Overshot water wheels with horizontal axles are the subject of this analogy.

2. I had a music teacher who believed this, too. He used to thwack my leg with his baton to make sure I didn't forget the beat. I recommend a kinder, gentler approach for your team. Although some in XP advocate a RolledUpNewspaper, visit the XP Wiki at http://c2.com/cgi/wiki?RolledUpNewspaper to learn more.