|An Iteration Planning Game
|This article presents a game board you can use to help
understand the iteration planning process.
- The team completed some number of story points ("weeks") last iteration.
- The Customer selects whichever unfinished stories they want, provided the
total story points fits that limit.
- Each Programmer completed some number of task points ("days") last
- Each Programmer puts that many coins in "their" box.
- The Customer picks a card and reads it aloud.
- The Programmers brainstorm the tasks required to implement that story.
(This will usually involve discussions with the Customer.) Write a task card
for each task identified.
- Continue until each story card has been read.
- Move the stack of cards to the unclaimed tasks pile.
- For each task, a Programmer will select it, estimate it in task points
("days"), and write their estimate on the card in pencil.
- If the task is bigger than 3 days ("too big"), the team can split the task
and put the new tasks on the unclaimed task pile.
- If the Programmer has fewer coins than their estimate ("too busy"), they
erase their estimate and return the card to the unclaimed task pile.
- Otherwise, the Programmer can accept the task, by removing as many coins
as their estimate, and adding the card to their stack.
- (This all happens in parallel as various Programmers claim various tasks.)
- Continue until the team gets stuck, needs more stories, or wins.
Team Gets Stuck: (can't find a way to win)
- The Customer picks a story to split or defer.
- Remove the corresponding tasks. Brainstorm new tasks for a split story.
- Try Phase 2 again.
Team Needs More Stories:
- There are Programmers who haven't used up all their coins, but the tasks
are all claimed.
- The Customer can add in another story and see if the team can fit it in.
- All tasks are accepted.
- The workload is reasonably balanced (everybody has about 0 coins left).
- The Manager writes up the iteration plan.
- Customers start writing tests.
- Programmers implement tasks.
Notes and Questions
How long should this take?
Half a day (to at most a day).
Why should the Customer have to split or defer a story if the team gets
stuck? If the team did so many story points last time, why can't they do that
many this time?
The estimate for the story was just that: an estimate. After the team has taken
the trouble to break it up into tasks and estimate them, they have better
information about the actual work involved.
But won't the team's schedule slip? The release plan said this story could
It might well affect the schedule. You hope there are other stories that come in
quicker than you asked to make up for it. If not, at least you know now.
How do you know who gets which task?
In XP, Programmers choose their tasks, rather than management assigning them.
There may be a little jostling, but the team should be able to devise its own
Why doesn't the whole team estimate the tasks? Shouldn't the team'sbest
estimate stand? (After all, that's the way you estimate stories.)
This is a key difference between release planning and iteration planning.One way
to think of this is: "The team owns the story, the Programmer owns the task;
therefore, the team owns story estimates and the Programmer owns task
estimates." There's a psychological reason as well: you're more likely to accept
an eestimate you made for your work than as estimate the team assigned to you.
Another reason is that personal estimates can be more accurate. Suppose Alice
finished 5 task points last iteration, and Bob finished 10. It's possible
they're equally productive, but just have a different estimation style. Neither
estimate, nor their average, is necessarily right for an arbitrary person on the
team. If a Programmer is consistently estimating and consistently productive,
their estimates will converge to the right number over time.
How many coins do you get the first time you play?
Start with 1/2 coin per day in the iteration (for each programmer).
How can a Programmer know how long to estimate for a task?
The Programmer can talk to the Customer or other Programmers, compare the task
to previous task estimates, do a quick spike (5-60 minutes), or go with a number
that "feels right".
What if a Programmer wants to do the wrong kind of task? (e.g., a GUI
programmer wants to do a database task)
XP's natural instinct is to avoid specialization, so this cross-training is
actually a good thing. Remember, this programmer will have a pair partner, and
they can work with someone who has experience in the area. Also, their
inexperience will tend to be reflected in their task estimate (higher than an
expert might say for the same task).
Can a Programmer make contingent estimates? (e.g., 1 day if Jan helps me,
Sure. Just make sure Jan is willing to play it that way, and don't let things
get too complicated.
Do we really have to use the game board?
No - of course not. (If you choose to, let me know how well it worked.) The game
board is a sort of poster than can remind you of how the iteration planning
Resources and Related Articles
[Written 6-9-2000; minor update 6-11-00.]