• Next: Slack
• Previous: Risk Management
• Up: Chapter 8: Planning

in 99 words

Iterations are timeboxed to one week and follow a strict schedule:

1. Plan iteration
2. Commit to delivering stories
3. Develop stories
4. Prepare release
5. Demonstrate release
6. Hold retrospective

To plan, measure the velocity of the previous iteration (total the estimates of "done done" stories). Select stories from the release plan that match the velocity. It shouldn't take long.

Assuming programmers are your constraint, they brainstorm and estimate engineering tasks. Ask the on-site customer about detailed requirements when necessary. Compare the task estimates to last iteration's to confirm the plan's feasability.

Post the stories and tasks prominently and mark them when complete.

New Information

Kanban Systems

Section Outline

• Iteration Planning
• The Iteration Timebox
• The Iteration Schedule
• How to Plan an Iteration
• The Commitment Ceremony
• After the Planning Session
• Dealing with Long Planning Sessions
• Tracking the Iteration
• When Things Go Wrong
• Partially Done Work
• Emergency Requests
• The Batman
• Sidebar: Daily Iterations
• Questions
  • How should we schedule time for fixing bugs?
  • If we don't estimate stories during iteration planning, when do we estimate stories?
  • All the available tasks depend on tasks that other pairs are working on right now. What should I work on?
  • What should the batman do when there are no outstanding support requests?
• Results
• Contraindications
• Alternatives
  • Iteration Length
• Further Reading

Full Text

This section will go online later this year. In the meantime, why not buy the book?

• Next: Slack
• Previous: Risk Management
• Up: Chapter 8: Planning