AoAD2 Practice: The Planning Game

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Revised: July 13, 2021

The Planning Game

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.”1 That’s what the planning game is. It’s a cooperative game designed to create the best possible payoff.

1This definition of “game” comes from Deardoff’s Glossary of International Economics:

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.

Visual Planning

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 releasing valuable increments.

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

How to Play

Every decision to do something is also a decision not to do something else.

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
Visual Planning

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” on page XX). For example, if you use the planning horizons shown in figure “Planning Horizons”, you would choose about one month’s worth of increments.

Kick off the planning game by reviewing the team’s purpose, describing how the increments you’ve chosen fit into the overall plan, and why these increments 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 questions the team has.

2. The whole team brainstorms stories

Use simultaneous brainstorming (see “Work Simultaneously” on page XX) 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” on page XX.

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” on page XX 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” on page XX). Note on the original story that the size is unknown. I usually write “spike” in the corner.

4. Customers prioritize the stories
Visual Planning

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 the team to consent to the plan (see “Seek Consent” on page XX). 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 “Key Idea: Minimize Work in Progress” on page XX.) 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 checkout 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 “Horizontal and Vertical Stripes”). Each builds on the previous, but you can release after each one.

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 1. Horizontal and vertical stripes

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.

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.

If a development decision isn’t optional, it isn’t a story.

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 burned toast. Which would you prefer?

Facing Reality

Customers, the planning game is almost certain to give you information that makes you unhappy. Even if your team isn’t making forecasts, the planning game will give you a rough idea of how much work there is to do. And, almost always, it will be more than you were hoping for.

Ignoring unpleasant reality won’t make the work take less time.

You may feel tempted to blame the messenger, and stop playing the planning game. Or you might pressure developers to not split stories. That would be a mistake. Ignoring unpleasant reality won’t make the work take less time; it just means you’ll be blindsided by delays. To paraphrase David Schmaltz: every release has a certain amount of disappointment associated with it. You can either use the planning game to dole out the disappointment in measured doses... or you can save it all up for the end.

Although your plan may be bigger than you like, if developers are asking you to split stories, it’s most likely because they want to set realistic expectations. In practice, I find that developers don’t split stories enough, at first, rather than the other way around. But if they do make their stories too small, it just means they’ll get more stories done, and you can compensate in your next planning game.

Iterating the Planning Game

Visual Planning

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. Afterwards, 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 only take 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.


How can we encourage stakeholders to use stories to request changes?

It’s not necessary. Instead, team members with customer skills should interpret stakeholders’ ideas and turn them into stories for the team.

What do we do about technical infrastructure?

Incremental Design
Simple Design
Reflective Design

Agile planning starts from the assumption that you can break your work into small, customer-centric stories, and build your technical infrastructure as you go. Evolutionary design shows how to do so.


Whole Team

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.


When you play the planning game well:

  • Customers and developers all feel they have contributed to the plan.

  • Feelings of pressure and stress are focused on the constraints of the plan, and possible options, rather than on individuals or groups.

  • Developers suggest options for reducing work while still fulfilling the team’s purpose.

  • Customers ruthlessly prioritize the stories that best serve the team’s purpose.

Alternatives and Experiments

The key idea of the planning game is that customers and developers come together to make a plan that’s better than either could make on their own. It’s a team-based approach, not an individual-based approach, and it’s focused on results, not tasks.

I haven’t seen anything that beats this core idea, but there’s room to experiment. For example, some teams prefer to create very small stories that can be finished in an hour or two. (Be sure to keep them customer-centric, though! Otherwise, they’re just tasks.) You can also experiment with the planning game agenda. For example, you could try creating and sizing your stories asynchronously, including more or fewer people, or planning more or less frequently.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.