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.

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.

Adaptive Planning
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. To recap:

  1. Purpose provides the overall goal (the vision) and current direction (the mission).

  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.

Task Planning

At the end of the planning game, you’ll have a set of stories that are “just right” for tracking progress and planning tasks. If desired, you’ll be able use them to judge capacity and make forecasts.

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’s effort on doing the things that provide the best return on the team’s time 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.

Whole Team

Neither group creates the plan unilaterally. Instead, both groups come together, each with their areas of expertise, and play the planning game:

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

Error on the side of too few increments. It’s easy to add more later.

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. Then explain the increments in more detail, including what makes them 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 the “Work Simultaneously” section) to come up with the stories needed to release each increment. The “Stories” practice describes how to create stories. 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 that you can’t size because you don’t understand them

  • Stories that 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 the “Capacity” practice.

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. The “Stories” practice 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. (You can create a cleaned-up version later, if you want.)

For stories you don’t understand, ask your customers to clarify. 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 the “Spike Stories” section).

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.

If you don’t have a visual plan, create a simple prioritized list. Identify one end of your conference table or virtual workspace as “first” and the other end as “last,” then arrange your stories in relative priority order. Create a single list—no ties allowed. This will force you to make important trade-off decisions.

Some stories won’t be worth adding. They’ll be unimportant or too far in the future. Go ahead and discard them. They won’t make sense later, and you’ll have better information in the future anyway. If you can’t stand to discard your stories, archive them somewhere out of sight.

Customers, make sure that you understand each story that 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’s too big or has too many unknowns.

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 24 stories.

It’s often most convenient to completely flesh out each increment, so you might end up with more stories than you technically need. For example, if your goal is to have 24 stories, and your two highest-priority increments had a total of 18 stories, you might bring in a third increment and end up with 29 stories total.

Once you have all the stories you need, 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?

  • Have irrelevant stories been discarded or archived out of sight?

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

Ask the team to consent to the plan (see the “Seek Consent” section). 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.

By “release,” I mean “available to be used.” Teams using continuous deployment deploy their software every day, but some improvements are turned off. They don’t count as “released” until they’re turned on. See the “Valuable Increments” section for details.

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”.) 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 that each of its stories stands alone. You should be able to release after every story. Subsequent stories can build on previous stories, but they shouldn’t depend on later stories.

For example, suppose you’re creating a checkout page that gets payment info from a user, validates it, and then charges their card. You might initially create a story for each layer of your architecture: “Get payment info on front-end,” “Store payment info on back end,” and “Process payment using third-party 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 the “Horizontal and Vertical Stripes” figure). 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-compatible countdown IC. The optical sensor is better, but we’d have to train a custom ML model, which is nice, because we’ve been wanting to dig into TensorDough. It’s very sophisticated, cutting-edge stuff that will allow us to detect the exact degree of brownness of the bread. The 555 is ancient tech and won’t give us dynamic detection abilities, but it won’t need any extra stories. 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?

For more ideas about how to phrase stories in terms of business priorities, see the “Stories” practice.

Facing Reality

Customers, the planning game is almost certain to give you information that makes you unhappy. Even if your team isn’t making estimates or 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.

Some people worry that developers will use the planning game to pad their work and slack off. That fear is misguided. In my experience, developers are highly-educated professionals who are motivated to meet customer expectations. Steve McConnell agrees: “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 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 and make more stories. 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 a team member with customer skills 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 and prerequisites?

Evolutionary Design
Evolutionary Architecture

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 and architecture show how to do so.

If you don’t want to use evolutionary design and architecture, then you’ll need other ways to split your technical infrastructure among your stories. Otherwise, you have to put development tasks in your visual plan, and that gets awkward quickly. It takes away customers’ agency and makes planning much more complicated. If you must, though, [Denne and Cleland-Huang 2004] describes an approach to planning that allows you to incorporate technical prerequisites.

How do we make time for paying off technical debt?


“Technical debt” is commonly used to refer to code that needs extra work to clean up. In general, you should have enough slack to clean up everything you touch, as part of every single story, so that you always leave your code better than you found it.

Sometimes, though, you’re dealing with code that needs extra attention. In that case, you can use clean-up stories. See the “Clean-Up Stories” section.


Whole Team
Evolutionary Design
Evolutionary Architecture

The planning game relies on several simplifying assumptions:

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

  • Team members with development skills you can reliably size stories.

  • Customer-centric stories with minimal dependencies on each other.

The final point requires that technical infrastructure be built incrementally, as part of your customer-centric stories. If you have trouble with this, you’ll need Delivering fluency, or at least evolutionary design and architecture.


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.