The Planning Game

AUDIENCE

Whole Team

Our plans take advantage of both business and development expertise.

You may know what you want to release, but how do you actually construct a step-by-step plan? That’s where the planning game comes in.

Despite the name, the planning game isn’t a trivial piece of entertainment. In economics, a “game” refers to a situation where “players select actions and the payoff depends on the actions of all players.”10 That’s what the planning game is. It’s a cooperative game designed to create the best possible payoff.

The planning game is notable for the way it maximizes the amount of information contributed to your plan. It’s strikingly effective. Although the planning game has limitations, if you work within them, I know of no better way to decide the details of your plan.

The planning game is just one part of your overall planning process. It’s a way of breaking valuable, releasable increments into smaller stories. At the end of the planning game, you’ll have a set of stories that are “just right” for development. To recap:

  1. Purpose provides the overall goal and current direction.

  2. Visual Planning identifies options for valuable increments.

  3. The Planning Game provides the step-by-step plan you’ll use to develop each increment.

How to Play

The goal of the planning game is to focus the team on work that provides the best return on investment. After all, every decision to do something is also a decision not to do something else.

Because developers have the most information about costs—they’re most qualified to say how much work it will take to implement a story—they size the stories.

Because on-site customers have the most information about value—they’re most qualified to say what is important—they prioritize the stories.

Team members that have both development and customer expertise can play both parts of the planning game, but it’s better if they stick to one role or the other. The benefits of the planning game come from resolving the natural tensions that arise between value and cost. It’s easy to fool yourself into ignoring those tensions when you play both roles.

1. Customers decide the scope of the plan

Product managers, prepare for the planning game by choosing the highest priority increments from the visual plan. Choose just enough to fill out your story planning horizon (see “How to Create Your Plan”). For example, if you use the planning horizons shown in Figure 8-2, you would choose about one month’s worth of increments.

Kick off the planning game by reviewing the team’s purpose, then describing how the increments you’ve chosen fit into the overall plan and why they are the most important to do first. Explain what makes the increments valuable and what needs to happen before they can be released, and answer any team questions.

2. The whole team brainstorms stories

Use simultaneous brainstorming (see “Work simultaneously”) to come up with the stories needed to release each increment. Write each one on an index card or virtual equivalent.

You may have some upcoming commitments, requests, or activities that don’t correspond to your top increments but need to be done anyway. Make stories for those, too. Anything that requires the team to do something other than normal company overhead needs a story.

3. Developers size the stories

Developers, review the story cards and sort them into several groups:

  • Stories that are just right

  • Stories that are too big

  • Stories that are too small

  • Stories you can’t size because you don’t understand them

  • Stories you can’t size because of technical unknowns

The stories are “just right” when the whole team can finish four to ten per week, or about six on average. Over time, you’ll get an intuitive sense for when a story is “just right.” To start out, though, you might want to use one of the estimating techniques described in “Estimating Stories”.

NOTE

Why four to ten stories per week? You can choose any size to be “just right,” but 4-10 is a good starting point. More than that, and you end up spending too much time creating, organizing, and tracking stories. Fewer than that, and you’ll have trouble making steady progress.

For stories that are too big, work with your customers to split them into smaller stories. “Splitting and Combining Stories” describes how. For stories that are too small, combine them with other stories. If you’re working with physical index cards, you can literally staple them together.

If you don’t understand a story, ask your on-site customers to clarify it. Sometimes, they’ll need to spend some time figuring it out. Continue on with the remaining stories while they do.

For stories that involve technical unknowns, make a spike story (see “Spike stories”). Note on the original story that the size is unknown. I usually write “spike” in the corner.

4. Customers prioritize the stories

Customers, once developers okay stories as “just right,” add them to your visual plan in rough order of priority.

For stories that don’t have a corresponding increment, add them wherever it makes the most sense to your team. Putting them among the other stories, according to priority, can help ensure they aren’t forgotten.

Some stories won’t be worth adding. They’ll be unimportant or too far in the future. Go ahead and discard them—they’ll be outdated by the time you get to them. If you can’t stand to discard your stories, archive them somewhere out of sight.

Customers, make sure you understand each story you add. You need to make good decisions about what’s “in” and “out” of each release, as well as deciding the order in which stories will be built, and that means the stories need to match your perspective. Don’t let developers bully you into adding a story you don’t understand.

Developers, you have final say over whether stories are “just right” and ready to be prioritized. Don’t let customers bully you into accepting a story that needs to be split or spiked.

5. Repeat until the plan is complete

Continue creating, sizing, and placing stories until you’ve filled out your story planning horizon. Bring in additional increments as necessary. For example, if you’re aiming for six stories per week and your story planning horizon is four weeks, continue until you have at least 24 stories. Then take a step back and double-check the plan:

  • Is every story sized “just right,” according to team members with development skills?

  • Does every story that couldn’t be sized have a spike story prioritized before it?

  • Have stories been prioritized correctly, according to team members with customer skills?

  • In general, does the plan make sense and lead to the team accomplishing its purpose?

Ask team members to consent to the plan (see “Seek consent”). When they do, you’re done.

Keep Your Options Open

Try to create a plan that allows you to release at any time. You don’t have to actually release all the time, but you want to be able to release at any time, even in the middle of working on an increment.

Why do this? It allows you to keep your options open. Normally, if an exciting new opportunity comes along while you’re in the middle of building an increment, you have to either wait until the increment is done, throw away the partially done work, or set it aside to metaphorically rust. (See “MINIMIZE WORK IN PROGRESS”.) But if you plan your work so that you can release at any time, you can decide that half of the increment’s value is better than nothing, release what you have, and start working on the new opportunity immediately.

To keep your options open, build your plan so you can release after every story. Stories can build on previous stories, but they shouldn’t depend on later stories.

For example, suppose you’re creating a check-out page that charges a user’s credit card. You might initially create a story for each layer of your architecture: “get payment info,” “store payment info,” and “send payment info to payment processor.” These are sometimes called horizontal stripes. It’s an easy way to create stories, but it prevents you from releasing your software until you finish all three stories. They form an all-or-nothing clump.

A better approach is to create stories that include all three horizontal layers but provide narrower individual utility. For example, you might create the stories “process payment,” “remember one card,” and “remember and manage multiple cards.” These are vertical stripes (see Figure 8-8). Each builds on the previous, but you can release after each one.

Don’t worry too much if you have trouble making your stories build on each other in this way. It takes practice. Being able to release after each story gives you more flexibility, but a few story clumps in your plan won’t hurt much. With experience, you’ll learn to make your plans less lumpy.

A diagram of a large box labelled “Application.” The box is split into three horizontal stripes and three vertical stripes. The horizontal stripes are labelled “front-end,” “back-end,” and “service integration.” The vertical stripes are labelled “Process payment,” “Remember one card,” and “Remember and manage multiple cards.”
Figure 8-8. Horizontal and vertical stripes

How to Win the Planning Game

When developers and on-site customers come together to play the planning game, something amazing happens. I call it the miracle of collaboration. It’s a miracle because time appears out of nowhere.

As you can imagine, this miracle isn’t easy to achieve. When developers say a story needs to be split, customers often ask a question that causes developers’ teeth to grind: “Why does it cost so much?”

The instinctive reaction to this question is defensive: “It costs so much because software development is hard! Why are you questioning me!?”

Developers, there’s a better way to react. Reword the question in your head: “Help me understand my options.” Answer by talking about what’s easy and what’s difficult.

For example, imagine that you’re building a toaster, and your product manager has a story to automatically pop up the toast when it’s done. Developers say the story needs to be split, and when the product manager asks why, the developers calmly answer, “Well, popping up the toast is easy; that’s just cutting power to the electromagnet. But detecting when the toast is done—that’s new. We’ll need an image sensor and machine learning to accurately detect changes in brownness across all types of bread. Marbled rye… that’s gonna be tricky. Not to mention toaster pastries!”

That 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 developers make a face. “Oh, that’s a total kludge. They don’t detect when the toast is done at all. They just use a timer.”

Now the product manager can reply, “That’s okay! Our customers don’t want a super toaster. They just want a regular toaster. Use a timer like everyone else.”

“Oh, okay. Well, that won’t be hard at all. We don’t need to split this story after all.”

In general, customers tend not to know what’s easy, and they end up creating stories that are difficult to implement. Similarly, developers tend not to know what customers think is important, and they end up creating stories that aren’t valuable.

With open and honest communication, these conflicting tendencies can be reconciled. When customers ask for something unimportant but difficult, developers point out the expense and offer easier alternatives. Customers change direction. Time appears out of nowhere. It’s the miracle of collaboration.

Prioritizing Development Decisions

On-site customers want to release a solid, usable product. They have to balance that desire with the desire to save money and meet market windows. As a result, they sometimes ask developers to skip important technical work. They do so because they aren’t aware of the nuances of development trade-offs in the same way that developers are.

Developers, you are the most qualified to make decisions on development issues, just as customers are most qualified to make decisions on business issues. If a development decision isn’t optional, it isn’t a story. Don’t ask customers to prioritize it. Just do it. Either don’t mention the work at all—it’s a detail—or mention it as part of the cost of doing business:

We need to create an automated build when we implement our first story. So we need the very first story to be something tiny, such as just showing the page title.

When there is a business choice to be made, don’t ask customers to choose between technical options. Instead, interpret the technology and describe the options in terms of business impact.

To revisit the toaster example, rather than describing the choice of optical sensor versus timer like this:

We’re thinking about using a Mark 4 Wizzle-Frobitz optical sensor here for optimal release detection. Our other option is to use a 555-style IC. The optical sensor is better, but we’d have to train a custom ML model. Which would you prefer?

Try this instead:

We have two choices for deciding when toast is done. We can use a camera or a timer. The camera will allow us to toast the bread to the user’s exact preference, but will require several more stories. The timer won’t take any extra work, but the user is more likely to have undercooked or burnt toast. Which would you prefer?

Iterating the Planning Game

As your team finishes stories, remove them from the plan. When it shrinks below your story planning horizon—for example, less than 24 stories—it’s time to play the planning game again. Afterward, double-check if you need to pull more increments into your visual plan.

Stakeholders will also suggest new ideas and features. Some won’t be worth doing and can be discarded (politely!). Others will be good ideas for future increments and can be added to the less detailed parts of your visual plan. Ideas you want to do soon, though, need stories. Those should be brought to the team to be sized and prioritized.

With practice, it should take only a few minutes to discuss, size, and prioritize a story. Accordingly, some teams review new stories the day they come in. Other teams schedule bigger planning game sessions every week or two. I find small, frequent sessions to be less tiring than big, less frequent sessions, but both approaches work.

Sometimes stakeholders will try to end-run the prioritization process by talking to programmers directly. The correct response is to listen to their request, write it down—I carry index cards with me for this exact purpose—and tell them it will be prioritized the next time your team meets to plan. Then you can hand it off to an on-site customer to follow up.

Prerequisites

The planning game relies on several simplifying assumptions:

  • Team members with customer skills who can make wise prioritization decisions

  • Team members with development skills who can reliably size stories

  • Customer-centric stories with minimal dependencies

The final point requires technical infrastructure to be built incrementally. If you have trouble with this, you’ll need Delivering fluency, or at least evolutionary design.

You also need to keep stories in a format that allows your team to work simultaneously. Typically, this means writing stories on index cards, or their virtual equivalent, rather than using a tracking tool.

10 This definition of “game” comes from Deardoff’s Glossary of International Economics.