XPlorations

Setup:

• 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 iteration.
• Each Programmer puts that many coins in "their" box.

Phase 1:

• 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.

Phase 2:

• 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.

Team Wins:

• All tasks are accepted.
• The workload is reasonably balanced (everybody has about 0 coins left).

Next:

• 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 be done.
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 accommodations.

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, otherwise 3)
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 process works.

Resources and Related Articles

• Extreme Programming Explored, by Bill Wake. This article is the basis for chapter 8.
• Extreme Programming Explained: Embrace Change, Kent Beck.
• "Simplified Iteration Planning," a newer, simpler version of iteration planning.

[Written 6-9-2000; minor update 6-11-00.]

Copyright 1994-2010, William C. Wake - William.Wake@acm.org