Goal: Practice iteration planning from a customer’s perspective.
Time: 20-60 minutes.
(Use only the most important stories, or cut down to small teams, to make the game play shorter.)
Introduction:
Briefly introduce the idea of story cards, release planning, and iteration planning. Explain that they (as customers) wrote and prioritized the stories during release planning, and now they’re going to schedule them into iterations, based on the release plan. Explain how the game will be played.
Material:
- Deck of pre-defined, pre-estimated story cards.
- A release plan that lists the stories in decreasing priority order.
- An estimate for the initial velocity: “5”.
- A 6-sided die.
- Somewhere to record iterations, in four columns: iteration #, planned velocity, actual velocity, total iterations expected.
Setup:
- Divide into teams of 2-6 people each. Each team designates a moderator/”programmer”; the rest are customers (together).
- Given the initial velocity and the story set (with estimates), have the customer team estimate the expected number of iterations.
Play:
- Repeat the following steps until all stories in the release plan have been completed.
- Use the number of story points completed in the previous iteration as the projected velocity for the current iteration.
- The customer team selects that many points worth of stories as the target for this iteration, and gives them to the moderator. (Record the planned value on the chart.)
- The moderator/programmer rolls the die to see how many are completed. (There’s no great harm if the customers see the die, but they don’t have to.)First time: only 2 points completed.
Second and following iterations: if a 1 or a 6, the same as the previous iteration; if 2 through 5, add three to the value on the die.
- Record the actual velocity, and compute a new total expected number of iterations.
- The moderator chooses that many points worth of stories and says “these completed.” If the gap is large, let the customers help choose the ones that are done. If the customers didn’t provide enough stories, they can give the moderator enough stories to make up the difference.
- Repeat until the stories in the plan have all been completed.
Debrief:
- Who decides which stories to attempt in each iteration, the customer or the programmers? [The customer]
- Do the same number of story points get completed each iteration? [No.]
- What if a story estimate is wrong? [Learn from the mistake and make better estimates. Split stories to make them easier to estimate.]
- How many story points do you plan for in the next iteration? [Yesterday’s Weather Rule]
- How many iterations will it take? [You don’t know – all you can do is estimate.]
- What if the programmers finish more stories than planned for an iteration? [They go to the customers for more stories, and their recorded velocity increases.]
- What if the programmers finish fewer stories than planned for an iteration? [They ask the customer to trim the plan (preferably before the end of the iteration). The team doesn’t slip the end date of the iteration – they reduce functionality instead (“timeboxed”).]
- Can’t the programmers just work overtime? [No – that can just slow them down. An occasional long week might be possible to overcome a short-term problem, but extended overtime is not an option.]
- What if the team just isn’t fast enough? [Split stories, so the most valuable part is done first; enlarge the team; get a better team.]
Source:
(William C. Wake, based on the planning game as described in Extreme Programming Explained.)