- Next: Slack
- Previous: Risk Management
- Up: Chapter 8: Planning
in 99 words
Iterations are timeboxed to one week and follow a strict schedule:
- Plan iteration
- Commit to delivering stories
- Develop stories
- Prepare release
- Demonstrate release
- 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
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
Subscribe (RSS)
Follow Me (Twitter)

Print

Loading comments...