The two players in the Planning Game are Development and Business. Development consists collectively of all the people who will be responsible for implementing the system. Business consists collectively of all the people who will make the decisions about what the system is supposed to do.
Sometimes it's easy to see who plays the part of Business in the Planning Game. If a bond trader is paying for a piece of custom-made software, then they get to be Business. They get to decide what is most important to do first. What if you are building a mass-market shrinkwrap product? Who is Business then? Business needs to make decisions about scope, priority, and the content of releases. These are decisions that are ordinarily made by the marketing department. If they are smart, they will support their decisions by referring to:
● Real users of the product ● Focus groups
● Salespeople
Some of the best players of Business I have seen have been expert users. For example, I worked on a customer service system for a mutual fund. Business was played primarily by a customer service supervisor who had worked her way up after working on the preceding system for years and years, and knew every detail of it. From time to time she had trouble separating what the new system should do from what the old system did, but after a while of working with stories she learned.
The Moves
There are three phases to the game.
● Exploration—Find out what new things the system could do.
● Commitment—Decide what subset of all possible requirements to pursue next. ● Steer—Guide development as reality molds the plan.
The moves from each phase are typically done in that phase, but not strictly. You will write new stories during the steering phase, for example. The phases are also cyclical; after you have been steering for a while you will need to go back to exploration.
Exploration Phase
The purpose of the exploration phase is to give both players an appreciation for what all the system should eventually do. Exploration has three moves.
Write a story—Business writes a story describing something the system needs to do. The stories are written on index cards, with a name and a short paragraph describing the purpose of the story.
Estimate a story—Development estimates how long the story will take to implement. If
Development can't estimate the story, it can ask Business to clarify or split the story. A simple method for estimating stories is to ask yourself, "How long would this take me to implement if this
story was all I had to implement, and I had no interruptions or meetings?" In XP we call this Ideal Engineering Time. As you will see below (in Set Velocity), before you commit to a schedule you measure a ratio between ideal time and the calendar.
Split a story—If Development can't estimate a whole story, or if Business realizes that part of a story is more important than the rest, Business can split a story into two or more stories.
Commitment Phase
The purpose of the commitment phase is for Business to choose the scope and date of the next release, and for Development to confidently commit to delivering it. The commitment phase has four moves.
Sort by value—Business sorts the stories into three piles: (1) those without which the system will not function, (2) those that are less essential but provide significant business value, and (3) those that would be nice to have.
Sort by risk—Development sorts the stories into three piles: (1) those that they can estimate
precisely, (2) those that they can estimate reasonably well, and (3) those that they cannot estimate at all.
Set velocity—Development tells Business how fast the team can program in Ideal Engineering Time per calendar month.
Choose scope—Business chooses the set of cards in the release, either by setting a date for engineering to be complete and choosing cards based on their estimate and the project velocity, or by choosing the cards and calculating the date.
Steering Phase
The purpose of the steering phase is to update the plan based on what is learned by Development and Business. The steering phase has four moves.
Iteration—At the beginning of each iteration (every one to three weeks), Business picks one iteration worth of the most valuable stories to be implemented. The stories for the first iteration must result in a system that runs end-to-end, however embryonically.
Recovery—If Development realizes that it has overestimated its velocity, it can ask Business what is the most valuable set of stories to retain in the current release based on the new velocity and estimates.
New story—If Business realizes it needs a new story during the middle of the development of a release, it can write the story. Development estimates the story, then Business removes stories with the equivalent estimate from the remaining plan and inserts the new story.
Reestimate—If Development feels that the plan no longer provides an accurate map of development, it can reestimate all of the remaining stories and set velocity again.