The first thing to do is to remind everyone what's on the menu for this iteration. It's often a good idea for the customer to read out the stories so that everyone hears them from the customer's perspective.

A short sentence on a card is enough to act as marker and reminder for a story. It certainly isn't enough to plan out a story, let alone write the code. So the customer needs to prepare for the iteration planning session by going into more detail about the stories. We've several ways of doing this.

You'll need the acceptance tests eventually, so tests are the best format for corroborating detail. It seems to be impossible to get the acceptance tests at the beginning of the iteration. The narrative is a reasonable facsimile, providing that everyone understands that the narrative is a supplement to conversation not a substitute for it.

You'll need to find out what works best in your environment. Over the course of a few iterations you should find what works best for your team.

Each story is a few ideal weeks of effort, so for this detail of planning we need to break the story down into a few finer-grained tasks. Each task should be a few ideal days of effort. The tasks are development tasks, so they don't need to make sense to the customer.

The best way to come up with the tasks is for everyone involved to just brainstorm what they might be. Often this will involve a little thought about how you're going to build the story. You don't need a major design effort here, but you do need just enough to get a good list of tasks. Take a short pass at the classes and interactions you'll need to add and modify. Remember that the goal is not to design everything that is needed for the iteration; it is to help figure what the best task breakdown is. You'll do other design sessions as part of carrying out the tasks.

Often you'll find overlap between the stories. This overlap may give you the opportunity to build software that helps satisfy several stories at once. There may be existing designs from past iterations that, with a little refactoring, could significantly help this iteration. Add tasks for this. It's great to have tasks that satisfy more than one story.

For example, several of the stories may require that as you enter text into a field you hunt for possible completions for that text from a given list. It would be a shame to develop this facility three or four times, once for each story. So make this into a task. It may be that other stories from past iterations need to have this new feature retrofitted onto them. You might make that retrofit a separate task.

You'll likely find dependencies between tasks. You won't need PERT charts or similar beasts. With a team that is communicating over a few weeks you can rely on the team to sort these dependencies out. It's worth talking them over, to influence what tasks are addressed first. However, as you'll see, you never plan precisely when each task gets done, or in what order the task gets done.

In the end there's no hard and fast rules for how you break something down into tasks. Use whatever approach makes sense for you. As long as the tasks are kept short and you can write tests for them, you'll be fine.

Most of your time will be spent in building stories. However, there are some purely technical tasks the customer doesn't care about but that still need to be done. These include installing the vendor's database upgrade, refactoring some messy bit of the system, trying out a design idea to learn if it will be useful, and improving the configuration control process. Anything like this should be added to the list. Again, it's important to keep each task small, so break the work into tasks of a few ideal days.

Ron Jeffries claims he can turn any technical task into a business-oriented story the customer can either schedule this iteration or not as she chooses. There's something to be said for not having any technical tasks. Once you start down the slippery slope of setting the priority for technical reasons, it's hard to stop. Dave Cleal suggests that a fixed portion of the budget, say 10 percent, be set aside for the programmers to spend as they like. We haven't tried it, but it sounds interesting.

How do you make sure individual programmers don't overcommit? During iteration planning there's pressure to be seen by the team to be doing your part. Fear of censure can overwhelm a programmer's experience.

We use Yesterday's Weather to reduce the chance of this happening regularly. Each programmer measures his velocity by tracking his accomplishments every iteration. A programmer can only sign up for the same number of days' worth of tasks as he completed last iteration.

There are good reasons to modify this number. If someone is spending one week of this three-week iteration on vacation, he will only have two-thirds of his velocity available.

A programmer's velocity is not a measure of productivity, speed, or goalkeeping ability. It just says how many tasks he can sign up for. One person may have a low velocity because he is naturally optimistic when estimating. Another may have a low velocity because he spends a lot of time helping other developers. It's more important for a programmer to make accurate predictions than for him to reach any arbitrary productivity measure. The absolute value of velocity is far less important than its predictive capability.

Once you have a list of the tasks on the whiteboard, programmers can then start signing up for them. By signing up, a programmer accepts the responsibility for working on that task during the iteration. The first thing she needs to do is to estimate how long it will take her to do the task.

It's up to the programmer to decide how to come up with an estimate. As usual, the best approach is to compare a task with previous work. The programmer can say, "This should take about the same time as the shipping GUI I did last iteration." The project records will show how long that task took, so that number can be used this time.

Be wary of using comparable work from another programmer. We are dealing with people, not Plug Compatible Programming Units. Programmers do not work at the same speed, and their speed will be different for a task. It's useful to let a programmer look at the records to help come up with an estimate, but don't say, "It only took Dinsdale three days to do this task, so why do you think it'll take you five?" Once you start using the records as a club, you'll never get an honest estimate again. The most important thing here is to get estimates as accurately as you can—if you want to compare programmers' abilities, don't do it during planning.

Programmers should always assume they have a partner when doing a task, since in XP all production coding is done in pairs. It may be that a particular partner can affect the estimate. "If Spiny will work with me on this, we can do it in two days." That's fine. Indeed it reinforces the principle that people help each other.

Programmers should also assume that they aren't done with a task until they have all the unit tests written and passing. "I'm done with the coding, but I haven't tested it yet," is a meaningless statement in XP. Code without tests simply doesn't exist for planning purposes.

Programmers can sign up for whatever they want to do. People can work on things they have a desire to do, which keeps them motivated. Since motivation is the key to productivity, this is a Good Thing. Some programmers will pick one kind of task they prefer and mostly do this. Others like to broaden their interests by trying new things. This is a Good Thing because it keeps up motivation, it allows developers to grow their skills, and it reduces project risk.

In iteration planning, as indeed in all of this book, we've focused on what the programmers do. How about the tasks others need to do: writing documentation, designing icons, and so on? In iteration planning we've seen some success from breaking down the work into tasks and just adding them to the list. Technical writers then sign up for the user manuals and artists sign up for icon design at the same time programmers sign up for programming.

Some project managers on hearing about this "signing up" practice fear there'll be some dirty work that doesn't get done. In practice we don't find this is an issue. Developers are so varied that there is almost always someone who likes doing anything. For occasional unpopular tasks, some informal and often unspoken sharing goes on.

If someone always ends up with the short end of the stick, ask the team to come up with a solution. Team members may choose to do a more formal rotation to take turns doing unpopular work. They may try to recruit someone to the team who likes doing this kind of work. Programmers like solving problems, so they'll find a solution. If they come up with the solution, they will work to make it fly.

Once all the programmers have signed up for tasks and estimated them, take a look at your task list. In a perfect world all the tasks will be signed up for. In this particular galaxy, we often find that some tasks remain unclaimed. If you have orphan tasks, which tasks do you defer?

Can you wait another iteration to upgrade the database? Sometimes waiting is the best option, but other times there aren't any technical tasks you think you can defer.

If no technical tasks can be defered, ask the customer. "We are short five ideal days. We need you to remove five ideal days' worth of story."

Customers can defer a whole story, or they can choose to split a story and defer one of the resulting parts (see "Splitting User Stories" on page49). A customer may choose to split several stories to get the right mix. A deferred story goes on the list for the next iteration. The customer can consider it again in two weeks.

You may be tempted to adjust the whole release plan if you defer a story. Don't rush to do that. Go for an iteration or two before you rework the release plan. Often the deferments are too small to be an issue right away. They need to build up before it's worth trying to deal with them.

Go ahead, laugh, but it does happen from time to time.

This process is the reverse of too much to do. The programmers ask the customer to add some stories. The customer can add a whole story or split a story and move a part in. However, as usual, the customer decides what gets moved, not the programmers.