Our plans take advantage of both business and technology expertise.
You may know when and what to release, but how do you actually construct your release plan? That’s where the planning game comes in.
In economics, a game is something in which “players select actions and the payoffs depend on the actions of all players.”[33] The study of these games “deals with strategies for maximizing gains and minimizing losses... [and are] widely applied in the solution of various decision making problems.”[†]
That describes the planning game perfectly. It’s a structured approach to creating the best possible plan given the information available.
The planning game is most notable for the way it maximizes the amount of information contributed to the plan. It is strikingly effective. Although it has limitations, if you work within them, I know of no better way to plan.
XP assumes that customers have the most information about value: what best serves the organization. Programmers have the most information about costs: what it will take to implement and maintain those features. To be successful, the team needs to maximize value while minimizing costs. A successful plan needs to take into account information from both groups, as every decision to do something is also a decision not to do something else.
Accordingly, the planning game requires the participation of both customers and programmers. (Testers may assist, but they do not have an explicit role in the planning game.) It’s a cooperative game; the team as a whole wins or loses, not individual players.
Because programmers have the most information about costs—they’re most qualified to say how long it will take to implement a story—they estimate.
Because customers have the most information about value—they’re most qualified to say what is important—they prioritize.
Neither group creates the plan unilaterally. Instead, both groups come together, each with their areas of expertise, and play the planning game:
Note
The planning game doesn’t always follow this neat and orderly format. As long as programmers estimate and customers prioritize, the details aren’t important. For example, the programmers may estimate a stack of stories all at once for the customers to prioritize later. Typically, most stories are created at the beginning of each release, during initial release planning sessions, as the team brainstorms what to include.
During the planning game, programmers and customers may ask each other questions about estimates and priorities, but each group has final say over its area of expertise.
The result of the planning game is a plan: a single list of stories in priority order. Even if two stories are of equivalent priority, one must come before the other. If you’re not sure which to put first, pick one at random.
Release planning is always a difficult process because there are many more stories to do than there is time available to do them. Also, each stakeholder has his own priorities, and balancing these desires is challenging. Tempers rise and the discussion gets heated—or worse, some people sit back and tune out, only to complain later. This struggle is natural and happens on any project, XP or not, that tries to prioritize conflicting needs.
Important
My favorite way to plan is to gather the team, along with important stakeholders, around a large conference table. Customers write stories on index cards, programmers estimate them, and customers place them on the table in priority order. One end of the table represents the stories to do first, and the other end represents stories to do last. The plan tends to grow from the ends toward the middle, with the most difficult decisions revolving around stories that are neither critical nor useless.
Important
Use index cards to focus disagreements away from individuals.
Using index cards and spreading them out on a table allows participants to point to stories and move them around. It reduces infighting by demonstrating the amount of work to be done in a visible way. The conversation focuses on the cards and their relative priorities rather than on vague discussions of principles or on “must have/not important” distinctions.
When customers and programmers work directly together throughout this process, something amazing happens. I call it the miracle of collaboration. It really is a miracle because time appears out of nowhere.
Like all miracles, it’s not easy to achieve. When programmers give an estimate, customers often ask a question that causes every programmer’s teeth to grind: “Why does it cost so much?”
The instictive reaction to this question is defensive: “It costs so much because software development is hard, damn it! Why are you questioning me!?”
Programmers, there’s a better way to react. Reword the customer’s question in your head into a simple request for information: “Why is this expensive?” Answer by talking about what’s easy and what’s difficult.
For example, imagine that a product manager requests a toaster to automatically pop up the toast when it finishes. The programmers reply that the feature is very expensive, and when the product manager asks why, the programmers calmly answer, “Well, popping up the toast is easy; that’s just a spring. But detecting when the toast is done—that’s new. We’ll need an optical sensor and some custom brownness-detecting software.”
This gives the product manager an opportunity to ask, “What about all those other toasters out there? How do they know when the toast is done?”
The programmers respond, “They use a timer, but that doesn’t really detect when the toast is done. It’s just a kludge.”
Now the product manager can reply, “That’s OK! Our customers don’t want a super toaster. They just want a regular toaster. Use a timer like everyone else.”
“Oh, OK. Well, that won’t be expensive at all.”
When you have honest and open dialog between customers and programmers, the miracle of collaboration occurs and extra time appears out of nowhere. Without communication, customers tend not to know what’s easy and what’s not, and they end up planning stories that are difficult to implement. Similarly, programmers tend not to know what customers think is important, and they end up implementing stories that aren’t valuable.
With collaboration, the conflicting tendencies can be reconciled. For example, a customer could ask for something unimportant but difficult, and the programmers could point out the expense and offer easier alternatives. The product manager could then change directions and save time. Time appears out of nowhere. It’s the miracle of collaboration.
Won’t programmers pad their estimates or slack off if they have this much control over the plan?
In my experience, programmers are highly educated professionals with high motivation to meet customer expectations. [McConnell 1996] validates this experience: “Software developers like to work. The best way to motivate developers is to provide an environment that makes it easy for them to focus on what they like doing most, which is developing software... [Developers] have high achievement motivation: they will work to the objectives you specify, but you have to tell them what those objectives are” [McConnell 1996] (pp. 255–256).
Although programmer estimates may be higher than you like, it’s most likely because they want to set realistic expectations. If the estimates do turn out to be too high, the team will achieve a higher velocity and automatically do more each iteration to compensate.
Won’t customers neglect important technical issues if they have this much control over the plan?
Customers want to ship a solid, usable product. They have to balance that desire with the desire to meet crucial market windows. As a result, they may sometimes ask for options that compromise important technical capabilities. They do so because they aren’t aware of the nuances of technical trade-offs in the same way that programmers are.
As a programmer, you are most qualified to make decisions on technical issues, just as the customers are most qualified to make decisions on business issues. When the customers ask for an explanation of an estimate, don’t describe the technical options. Instead, interpret the technology and describe the options in terms of business impact.
Rather than describing the options like this:
We’re thinking about using a Mark 4 Wizzle-Frobitz optical sensor here for optimal release detection. We could use a Mark 1 spring-loaded countdown timer, too. We’d have to write some custom software to use the Mark 4, but it’s very sophisticated, cutting-edge stuff and it will allow us to detect the exact degree of brownness of the bread. The Mark 1 is ancient tech without dynamic detection abilities, but it won’t take any extra time to implement. Which would you prefer?
Try this instead:
We have two choices for popping up toast. We can use either an optical sensor or a timer. The optical sensor will allow us to toast the bread to the user’s exact preference, but it will increase our estimate by three days. The timer won’t take any extra time but the user is more likely to have undercooked or burned toast. Which would you prefer?
If a technical option simply isn’t appropriate, don’t mention it, or mention your decision in passing as part of the cost of doing business:
Because this is the first iteration, we need to install a version control system. We’ve included that cost in the estimate for our first story.
Our product manager doesn’t want to prioritize. He says everything is important. What can we do?
Be firm. Yes, everything is important, but something has to come first and something will come last. Someone has to make the tough schedule decisions. That’s the product manager’s job.
Important
When you play the planning game well, both customers and programmers feel that they have contributed to the plan. Any feelings of pressure and stress are focused on the constraints of the plan and possible options, rather than on individuals and groups. Programmers suggest technical options for reducing scope while maintaining the project vision. Customers ruthlessly prioritize the stories that best serve the vision.
The planning game is an easy, effective approach that relies on many of XP’s simplifying assumptions, such as:
Customer-centric stories
Story dependencies that customers can manage effectively (in practice, this means no technical dependencies and simple business dependencies)
Customers capable of making wise prioritization decisions
Programmers capable of making consistent estimates
If these conditions are not true on your team, you may not be able to take advantage of the planning game.
Important
The planning game also relies on the programmers’ abilities to implement design and architecture incrementally. Without this capability, the team will find itself creating technical stories or strange story dependencies that make planning more difficult.
Finally, the planning game assumes that the team has a single dominant constraint (for more information about the theory of constraints, see XP Concepts” in Chapter 3). It’s very rare for a system to exhibit two constraints simultaneously, so this shouldn’t be a problem. Similarly, the planning game assumes that the programmers are the constraint. If this isn’t true for your team, discuss your options with your mentor.
There are a wide variety of project planning approaches. The most popular seems to be Gantt charts that assume task-based plans and schedule what each individual person will do.
In contrast to that approach, the planning game focuses on what the team produces, not on what individuals do. The team has the discretion to figure out how to produce each story and organizes itself to finish the work on time.
This focus on results, rather than on tasks, combined with the planning game’s ability to balance customer and programmer expertise, makes it the most effective approach to software planning I’ve experienced. However, if you wish to use another approach to planning, you can do so. Talk with your mentor about how to make your preferred approach to planning work with the rest of the XP practices.
[33] Deardorff’s Glossary of International Economics, http://www-personal.umich.edu/~alandear/glossary/g.html.
[†] Dictionary definition of “game theory,” http://dictionary.reference.com/search?q=game theory&x=0&y=0.