Iteration Planning
Iterations are the heartbeat of an XP project. When an iteration starts, stories flow in to the team as they select the most valuable stories from the release plan. Over the course of the iteration, the team breathes those stories to life. By the end of the iteration, they’ve pumped out working, tested software for each story and are ready to begin the cycle again.
Iterations are exactly one week long and have a strictly defined completion time. This is a timebox: work ends at a particular time regardless of how much you’ve finished. Although the iteration timebox doesn’t prevent problems, it reveals them, which gives you the opportunity to correct the situation.
An iteration follow an unchanging schedule.
- Demonstrate previous iteration
- Hold retrospective on previous iteration
- Plan iteration
- Commit to delivering stories
- Develop stories
- Prepare release
Team usually start their iteration on Monday morning and end Friday evening. Some others start their iteration on Wednesday morning. They do this because it allows people to leave early on Friday or take Monday off without missing important events and also because it allows the team to conduct releases before the weekend, which is an important aspect of iteration planning.
Planning an iteration
After the iteration demo and retrospective are complete, iteration planning begins. Start by measuring the velocity of the previous iteration. Take all the stories that are “done done” and add up their original estimates. This number is the amount of story points we can reasonably expect to complete in the upcoming iteration.
With our velocity in hand, we can select the stories to work on the current iteration. Ask your customer to select the most important stories from the release plan. Select stories that exactly add up to the team’s velocity. You may need to split stories or include one or two less important stories to make the estimate add up perfectly.
Because the iteration planning meeting take stories from the front of the release plan, you should have already estimated and prioritized those stories. As a result, selecting stories for the iteration plan should only take a few minutes, with perhaps 10 or 15 minutes more to explain.
At this point, the real work of iteration planning begins. Start by breaking down the stories into engineering tasks.
Engineering tasks are task for programmers to complete. Unlike stories, engineering tasks don’t need to be customer-centric. Instead, they're programmer-centric. Typical engineering tasks include:
- Update build script
- Implement domain logic
- Add database table and associate ORM objects
- Create new UI form
Brainstorm the tasks you need in order to finish all the iteration’s stories. Some tasks will be specific to a single stories others not. Brainstorming tasks is a design activity. If everybody has the same ideas about how to develop the software, it should go fairly quickly. If not, it’s a great opportunity for discussion before coding begins. However you should not go into much details.
After you’ve finished brainstorming tasks, spread the out on the table and look at the whole picture. Are these tasks enough to finish all the stories? Are there any duplicates or overlaps? Discuss and fix any problem.
Afterwards go on with the next step required: Estimate the tasks.
As with brainstorming, this can occur in parallel, with individual programmers picking up cards, writing estimates, and putting them back. Call out the estimates as you finish them. If you hear somebody call out an estimate you disagree with, stop to discuss it and come to consensus.
It’s important to estimate the tasks in ideal hours. How long would the task take if you had perfect focus on the task, suffered no interruptions, and could have the help of anybody on the team? Estimate them in person-hours as well: a task that takes a pair two hours is a four-hours estimate. If any of the tasks are bigger than six hours of effort, split them into smaller tasks and consequently combine small tasks that are less than an hour or two.
As final step, add up the estimates and compare them to the total task estimates from your previous iteration. Using this plan, you can commit to delivering all the stories? Is there any slack in the plan for dealing with unexpected problems?
Doing so, you may discover that you aren’t comfortable committing to the plan you have. If so, see if there are any tasks you can remove or simplify. Talk with your on-site customer. Can you replace a difficult part of a story with something easier but equally valuable? If not split or remove the story. Similarly, if you feel that you can commit to doing more, add a story to the plan.
Experience leads making plans that don’t need adjustment.
