AoAD2 Practice: Visual Planning

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.

Visual Planning

Product Managers, Customers

We have a map for achieving our purpose.

Your plans are the key to achieving your team’s purpose. Rather than building your plan as a dry, dead list, create a plan that lives and breathes. Rather than showing what to do, show options, relationships, and create the ability to make choices. Strike off the shackles of simple prioritization and let your plans fly free.

A visual plan allows you to visualize your choices and adapt your plans.

More prosaically, visual planning is a way of mapping out your options. Rather than saying “do this, then this, then that,” a visual plan allows you to visualize your choices and adapt your plans as you go.

Real Customer Involvement

Visual planning is led by the team’s product manager, with the assistance of the team’s other on-site customers. Do your best to include key stakeholders, too, at least for high-level planning. Their perspective will improve the quality of your plans.

Your visual plan is an example of a boundary object (see the “Create Visualizations” section): a way to communicate and combine the perspectives of various groups.

Developers can be heavily involved, or not, as your team sees fit. Some developers prefer not to attend yet another meeting—and, in truth, it’s possible that their time could be better spent elsewhere. On the other hand, developers’ work will benefit from an in-depth understanding of the plan, and their perspective often leads to better plans. I tend to leave it up to each individual developer to decide. When in doubt, include them.

Some product managers prefer to create the first draft of their plan by themselves, or with just one or two other participants. That’s fine, so long as you eventually include broader perspectives. Developer and stakeholder feedback will help you make sure nothing important is missed.

The Planning Game

Even if developers don’t attend, they still need to understand the plan and provide feedback. Be sure to set aside time to discuss the plan with developers. The planning game might be a good time to do so.

How to Create a Visual Plan

The right visualization is the one that works for your team and its stakeholders.

The possibilities for visual plans are endless. Here, I discuss four techniques. You follow one of these techniques as written, mix and match between them, or create new visualizations that are wholly your own. The right visualization is the one the works for your team and its stakeholders.

Cluster mapping

Cluster mapping is the simplest and most flexible way to visualize your plans, and also one of the most effective. It’s my go-to technique.

A diagram of a whiteboard. The board is labelled, “release plan.” A line divides the board into left and right halves. The left half is labelled, “Next release Aug 1.” It has three SIV cards, numbered 1, 2, and 3. Each SIV has 5-10 story cards organized in a cluster beneath it. The right half of the board is labelled, “Future releases.” It has two more clusters of a SIV with story cards (similar to the left hand side). The SIVs are numbered 4 and 5. It also another SIV with just one story, without a number, and then three clusters of only SIV cards. One of them consists of two cards and is labelled, “pick one.”

Figure 1. A cluster map

Team Room

To create a cluster map, use simultaneous brainstorming (see the “Work Simultaneously” section) to generate SIVs and stories that will help your team fulfill its purpose. (Remember, SIVs are shippable increments of value, and stories are smaller pieces that may not be shippable on their own. See the “Shippable Increments of Value” section and the “Divide SIVs Into Stories” section.)

Focus more on SIVs than stories. You’re starting with a high-level map, not a detailed plan. The important thing is to think about your team’s purpose and what could help achieve it. But sometimes it’s easier to brainstorm stories and later combine them together into SIVs, so feel free to create both.

Be brief. You can always add more detail later.

For each SIV and story, write a brief phrase on an index card or its virtual equivalent, such as “TPS Report” or “Allow subscribers to change subscription tier.” Don’t worry about the phrasing. You just need to write enough to act as a reminder. You can always add more detail later.

If you have a virtual team room, use your free-form collaboration tool. If you have a physical team room, put the cards on your conference table or release planning board.

I like to color-code my cards. (I use red for SIVs and blue for stories.) For this exercise, though, don’t stress if a SIV turns out to be a story, or vice-versa. You can fix the colors later.

Once you’re done brainstorming, use affinity mapping (see the “Work Simultaneously” section) to cluster the SIVs and stories. As you work, you’ll probably come up with more ideas. Go ahead and add them.

Some of your cards will be duplicates, and you can either discard or combine them. When using physical index cards, the easiest way to combine cards is to literally staple them together. You can create cleaned-up versions later, if you want.

If you brainstormed a lot of stories, they’re likely to form clusters of their own. Create a SIV for each cluster. You can either discard the stories—you’ll have a chance to make better stories during the planning game—or you can keep them grouped together with their SIV. With physical cards, sometimes it’s useful to use a rubber band or binder clip to attach the stories to their associated SIV.

When you’ve finished your affinity map, transfer it to your release planning board, if it isn’t already there. Then take a step back and review. Tweak the clusters and add notes that make the map easier to explain. You want to be able to use the map as a visual aid to describe how your team is going to achieve its purpose.

Some cards, or even clusters, could represent different ways of accomplishing the same thing. If you’re not sure which choice you want to make, leave the both on the board! Your plan is a map, and maps show multiple routes to a destination. You might even want to make some experiment-style SIVs to help you choose between options.

Some clusters or cards may turn out to be irrelevant to your current purpose, or too far in the future. Go ahead and discard them for now. If you can’t stand to do that, archive them somewhere out of sight. Keep your map focused on what matters.

Speaking of purpose, you may have some work to do that isn’t directly related to your team’s purpose, but has to be done anyway. If you haven’t made cards for those needs, go ahead and do so, and add them to the board.

At this point, you have a complete high-level plan showing the SIVs that your team could work on. This is a good time to take a break and get feedback from team members and stakeholders who didn’t attend. Next, you’ll go into more detail.

Breaking down SIVs
Adaptive Planning

As described in the “Adaptive Planning” practice, your plan will consist of multiple levels of detail (see the “How to Create Your Plan” section). Your visual plan involves these levels:

  1. Purpose

  2. High-level SIVs

  3. Smallest possible SIVs

  4. Stories

You started with your team’s purpose and used that to create high-level SIVs. Now you’ll break them down further. Starting with your most valuable SIVs, brainstorm smaller SIVs that are still shippable and valuable. For example, if your product is an online store and you have an “enhanced checkout page” SIV, you could break it down into “remember credit cards,” “check out with PayPal,” “gift wrapping,“ “coupons,“ and so forth.

Sometimes it’s helpful to brainstorm the stories associated with each SIV, then move them around to form clusters representing smaller SIVs. If that doesn’t help, don’t worry; you can always split your SIVs later.

Keep going until you’ve broken down enough SIVs to fill your “small SIV” planning horizon. For example, if you use the planning horizons shown in the “Planning Horizons” figure, you would stop when you had about three months worth of small SIVs.

Just use your gut feel about when to stop. You don’t need to get a proper development estimate: you’re not committing to anything and there’s no harm if you get it wrong. If you don’t break down enough SIVs, you’ll just do more later; if you break down too many, you’ll just have done more planning than you needed to.

When your SIVs are as small as you can make them, prioritize them by marking each one with a number. (No ties allowed!) If you’re using physical index cards, put the number on a small sticky note and stick it to the card. As your priorities change, you can move the sticky notes without rewriting the cards.

That finishes off the “small SIVs” level of detail. This is another good time to take a break and get feedback.

The Planning Game

The final level of detail for your visual plan is to break your small SIVs into stories. Use the planning game to do so. When you’re done, you’ll have a set of stories for each of your highest-priority SIVs. Add each set to the board near its corresponding SIV. The final result will look something like the “A Cluster Map” figure.

Impact mapping

Sometimes you want more structure than cluster mapping provides. Goyko Adzic’s Impact Mapping [Adzic 2012] is a great tool for helping you explore your options.

Find the shortest path through the map to your goal.

Never aim to implement the whole map. Instead, find the shortest path through the map to the goal! [Adzic 2012] (pp. 12-13)

Gojko Adzic

A diagram of a whiteboard. The board is labelled, “release plan.” In the center of the board is a circle with the text “$200K MRR, >20 NPS.” The circle is labelled “why (goal).” Several levels of cards (shown as simple rectangles) extend from the center circle in the manner of a mind map. Starting with the first, the levels are labelled “who (actors),” “how (impacts),” “what (deliverables),” and “small SIVs.” Some of the “how“ cards are covered in dots; they’re labelled “dot votes.” The cards with a lot of dots are the only ones that have “small SIV” cards. Five of the small SIVs are prioritized 1-5, and the first three have a set of cards labelled “stories” next to them.

Figure 2. An impact map

An impact map is a type of mind map. In case you aren’t familiar with them, mind maps are hierarchical trees of ideas. You start with the core idea in the center of the map. Ideas related to that core idea branch out from the center to create their own nodes. For each of those ideas, additional ideas branch out. And so forth.

In the case of an impact map, “Why” (goal) goes in the center, followed by “Who” (actors), “How” (impacts) and “What” (deliverables).

To create the impact map, use your release planning whiteboard (if in person) or a collaborative mind mapping tool (if remote). You can use your free-form collaboration tool if you don’t have a mind mapping tool. If you’re using a physical board, you might want to use index cards for the nodes. That will make it easier to move them around as needed. As always, work simultaneously rather than bottle-necking contributions behind a single person.


Start with your goal. This is the “Why” of the impact map, and it goes in the center. Your goal should relate to your team’s purpose in some way. It might be a condensed version of your mission, the next relevant mission tests, or both. In an impact map, everything stems from the goal. This is the destination your map will show you how to reach. To use the Team Sasquatch example (see the “An Example Purpose” sidebar), your goal might be “$200K MRR, >20 NPS.”


Put actors that relate to the goal as the next level of your map. This is the “Who” level, and it includes everyone, other than your team, that can either help or hinder your team’s ability to reach the goal. If you’ve created a context diagram (see the “Boundaries and Interactions” section), the stakeholder groups in that diagram are a good starting point. Be sure to include actors with potentially negative impacts, such as competitors. Examples include “customers,” “prospects,” “sales and marketing,” and “regulators.”

Next comes impacts: the “How” of the impact map. Think of they way each actor could affect your goal. How could they help? How could they get in the way? How do you want the actor’s behavior to change? For example, existing customers could “recommend us on social media" or industry journals could “post positive reviews.” Be sure to include negative impacts, such as regulators who “increase auditing requirements“ or competitors who “change pricing model.” Talk about how the behavior is different than today; if regulators already require auditing, the impact isn’t just “require audits,” it’s “increase auditing requirements.”

Up until now, you’ve been thinking broadly and generating options. Now it’s time to focus your thinking. Which impacts are critical for meeting your goal? Which represent low-hanging fruit? Which represent assumptions that need to be tested? Choose the impacts that are the highest priority. In a group setting, dot voting can help (see the “Work Simultaneously” section).

The purpose of the impact map is to focus your attention on your goal and impacts.

Now you’re ready for deliverables, or the “What” of the impact map. These are your high-level SIVs. It’s tempting to think of deliverables as the most important part of the map, but they’re not! The purpose of the map is to focus your attention on your goal and the impacts you want to achieve (or mitigate). SIVs are what you use to do so, but it’s like saying your car is the most important part of a road atlas. Necessary for the trip, yes. The map—no.

For each impact, think of ways your team could support the impact (for positive impacts) or mitigate the impact (for negative impacts), or learn more about the impact (for assumptions that need testing). Keep your ideas high level. For example, to support customers recommending you on social media, you could add “Automatically post screen shots“ and “Post celebrations.” Later, you’ll create small SIVs such as “Post screen shot to Twitter” or “Facebook post celebrating new record.”

At this point, you have a high-level plan. Next, you’ll break the high-level SIVs down into small SIVs, and those further down into stories, using the approach described in the “Breaking Down SIVs” section. Add each level of detail onto your impact map: small SIVs attach to their corresponding “What“ node, and stories attach to their corresponding small SIV. The final result will look something like the “An Impact Map” figure.

Prospective analysis

Prospective analysis helps you generate ideas by imagining future outcomes. It’s particularly good as a risk management tool. You can use the prospective analysis as a planning tool on its own or as a lead-in to another planning approach.

A diagram of a whiteboard. The board is labelled, “release plan.” In the center of the board is a circle with the text “$200K MRR, >20 NPS.” The circle is labelled “why (goal).” Several levels of cards (shown as simple rectangles) extend from the center circle in the manner of a mind map. Starting with the first, the levels are labelled “who (actors),” “how (impacts),” “what (deliverables),” and “small SIVs.” Some of the “how“ cards are covered in dots; they’re labelled “dot votes.” The cards with a lot of dots are the only ones that have “small SIV” cards. Five of the small SIVs are prioritized 1-5, and the first three have a set of cards labelled “stories” next to them.

Figure 3. A prospective analysis

One type of prospective analysis is an Impact and Probability chart, described in Diana Larsen and Ainsley Nies’ book Liftoff: Start and Sustain Successful Teams [Larsen and Nies 2016]. It’s simple and effective.

To create the chart, draw a large graph on your release planning board or virtual equivalent. Label the vertical axis from -3 to +3 and draw a horizontal dashed line at the “0” mark. For the horizontal axis, label a range from “Won’t happen” to “50/50” to “Will happen.” Draw a vertical dashed line at the “50/50” mark.

Now use simultaneous brainstorming to think of what might happen in your team’s future—to the team, their stakeholders, and their software. Write each one on an index card. Be sure to think of positive results as well as negative.

Participants can add their cards to the chart immediately, or wait until the brainstorming is done. When you add them to the chart, position them according to the likelihood of the card happening (the horizontal axis) as well as the impact of the card happening (the vertical axis). The impact can range from “very bad“ (the “-3” mark) to “neutral“ (“0”) to “very positive“ (“+3”).

After the cards are on the board, take a moment to review and adjust their positions. This can be done simultaneously, similarly to affinity mapping or mute mapping. (See the “Work Simultaneously” section.) The result will look something like the “A Prospective Analysis” figure.

Next, use dot voting to choose the cards that are most important to address. You can use these priorities as input into one of the other visualizations. If you’re using the prospective analysis as a stand-alone plan, brainstorm high-level SIVs that will help achieve positive outcomes and mitigate negative outcomes. Add them next to the chart with arrows pointing to their corresponding cards.

Finally, break the high-level SIVs down into small SIVs and stories as described in the “Breaking Down SIVs” section.

Story mapping

Jeff Patton’s story maps are particularly useful when you’re building out new user interfaces. It provides a map for building user interaction flows incrementally. Story maps can be used on their own, or used to flesh out a subset of a larger plan created with the one of the other approaches.

A diagram showing a grid of cards (shown as simple rectangles). The top two rows of the grid are labelled “user activities” and “user tasks.” There’s a horizontal line below the second row. Each user activity card is associated with several user task cards, and the tasks are divided into six columns. The columns are labelled “SIVs.” The first three columns have additional cards and the last three columns are empty. In the first three columns, vertical rows of cards are grouped into several boxes, labelled “small SIVs.” Five of the boxes are labelled with numbers from one to five.

Figure 4. A story map


To create a story map, start by reviewing your purpose and context. Who are the users that will use your software? If they’re not the people paying for it, who are the choosers who will pay for your software? What benefits do they each get? How does that relate to your team’s purpose and the value your organization expects?

Next, map out the big picture. Starting with the most important users, brainstorm user activities—things they want to to use your software to do. Other systems can also be users. As always, you can brainstorm simultaneously (see the “Work Simultaneously” section). Patton gives the example of an email application, with activities such as “managing email,” “configure email servers,” and “set up out of office responses.” Write each one on an index card, sticky note, or virtual equivalent. A short phrase is enough.

Story maps can take up a lot of space. If you have a physical team room, you may want to use a large wall and sticky notes rather than a whiteboard and index cards. “Super sticky” sticky notes are best for longevity—you don’t want to come in after a long weekend and find your plan on the floor!

For each activity, brainstorm user tasks that users will perform to accomplish their activities. For the “managing email” activity, Patton gives the examples of “send message,” “read message,” “delete message,” “mark message as spam,” and so forth. Arrange them in the order that the tasks will be performed, and put them under each activity in a horizontal line.

As you work, tasks will inspire more activities and users, which will in turn inspire new tasks. Keep going until you have a broad overview of the ways people and systems will use your software, organized with the most important activities and tasks first.

Validate the map by “walking the board“ from start to finish, like this: “Our first activity is ‘managing email.’ Users will send messages, read messages, delete messages...” Now may be a good time to take a break and get feedback from developers, users, and other stakeholders.

Next, you’ll go into more detail. Starting with your most important activities and tasks, identify sets of cards that are independently shippable. Draw vertical lines to group them into high-level SIVs. Choose several to ship first, according to your “small SIVs” planning horizon.

Think broadly and come up with a variety of options.

For the SIVs that you’ve chosen, brainstorm subtasks and user interface details for each user task. Write them on cards, sticky notes, or their virtual equivalent, and arrange them vertically under their task according to priority. For example, for the “send message“ task, you might create cards such as “compose plain text message,” “compose HTML message,” “send via POP,” “send via SMTP,” “embed image,” “add attachments,” and so forth. Use this opportunity to think broadly and come up with a variety of options, without worrying about what’s in scope.

Now you can break your SIVs down into the smallest possible SIVs. For each SIV, choose sets of subtasks that can be shipped independently. Draw a horizontal line and move the remaining subtasks below the line. Repeat until each vertical column is divided into boxes. Each box represents a small SIV. Number each box in order of priority.

The Planning Game

Your next step will be to use the planning game to refine your stories. This is another good opportunity to take a break and get feedback. When you’re ready for the planning game, use the cards in each box as your initial stories. When you’re done, put the final set of stories back into your story map. The final result will look something like the “A Story Map” figure.

Iterating the Visual Plan

Update and improve your plan frequently.

Whichever visualization you choose, update and improve it frequently. The product managers I’ve known are constantly looking at and tweaking their plans. One put his cluster map in a shoebox and carried it with him everywhere. (He used binder clips to group the cards into clusters.) He was constantly spreading it out in meetings and making little changes.

At the very least, check in on your plan every week. Every time the team finishes a story or SIV, check your planning horizons and pull out more detail, as described in the “How to Create Your Plan” section.


What if we have to use a corporate planning tool that doesn’t allow us to make our own visual plans?

Don’t let your tools prevent you from making and customizing your visual plan. If you’re required to use a restrictive tool, treat it as another view into your plan. Use the visual plan as your source of truth and copy information into the corporate tool as needed. It’s wasteful to duplicate effort, of course, but a good visual plan is so valuable, it’s worth it. Over time, you may be able to convince management to relax the requirement. (See the “Delegate Authority and Responsibility to Teams” section.)

How do we convert our visual plan into a format that our organization and stakeholders want to see?


There are a variety of options depending on how much detail your organization needs. See the “Roadmaps” practice for details.


Team Room

Visual planning requires a team room designed for collaboration. For a virtual team room, this requires a free-form collaboration tool. For a physical team room, it requires a large table, magnetic whiteboard, and index cards or sticky notes.

Don’t use a dedicated planning tool. You need the ability to visualize, customize, and experiment.

It’s tempting, but don’t use electronic tools for your plan. If you’re a virtual team, you’ll have to use a free-form collaboration tool, but even then, don’t use a dedicated planning tool. They’re too restrictive, and most are limited to simple priority lists. You need the ability to visualize, customize, and experiment.

So-called Agile planning tools, also known as “Agile Lifecycle Management” tools, are anything but Agile. They’re built for the whims of big Cargo Cult Agile companies. They will harm your agility. Avoid them.

Informative Workspace

For in-person teams, physical maps are dramatically more effective than electronic maps, even with a free-form tool. The physical map forms an important part of your informative workspace. Their tactile, large-scale nature connects with our brains in a way screens just can’t. It’s hard to appreciate how much of a difference this makes until you’ve experienced it. Make an extra effort to use physical plans.

Whole Team

Visual planning also requires the leadership of people with product management and customer skills. Without their participation, you can still create a visual plan, but it may not be a good plan. A clear purpose is also essential.

Real Customer Involvement

For best results, include key stakeholders in your planning sessions, or at least solicit their feedback on your draft plans. Without stakeholder feedback, you run the risk of tunnel vision. You could build something that seems right to you, but doesn’t actually fulfill stakeholder needs.


When you create and communicate a visual plan well:

  • Stakeholders and team members not only understand what will be done, they understand why it will be done.

  • The relationships between the parts of your plan are easy to see.

  • Stakeholders and team members contribute new ideas as a result of their deeper understanding of context.

Alternatives and Experiments

You can start experimenting with this practice right away. Try each of the maps described here, mix and match, and include your own ideas. Find the approach that speaks best to you, your team, and your key stakeholders. There’s no right answer, so experiment with as many ideas as you can find or think of. Don’t be afraid to change things up, either; I change my visualizations every few months, and it always gives me new insights and fresh excitement for possibilities.

There are many ways of visualizing plans. One startup I worked with created a chart of business priorities in four categories (“business development,” “cost control,” “risk mitigation,” and “improving capacity.”) Each idea got an sticky note that was ordered by priority. There were hundreds of ideas—far more than the team could ever accomplish—and only a few were labelled with as top priorities. The rest were constantly moving around as the startup founders came up with new ideas and reconsidered old ones.

Another team had a lot of small date-based commitments. They created a commitment calendar with a column for each week. Cards representing the commitments due each week were put in the corresponding column. Every week, the team reviewed upcoming commitments and included them in that week’s task planning.

There are many more options available. Experiment freely! With one exception: Wait at least three months before using a dedicated planning tool. Even the better ones are terribly constraining, but it’s hard to see why that’s a problem until you’ve experienced the power and flexibility of a free-form approach.

Further Reading

Impact Mapping [Adzic 2012] is the definitive guide to impact maps. It’s a short, easy read, and chock-full of useful advice. If you’re using impact maps, it’s well worth getting.

Liftoff: Start and Sustain Agile Teams [Larsen and Nies 2016] talks about prospective analysis on pp. 95-97. It doesn’t say much than I do here, but it has a lot of other good material about chartering and facilitation.

XXX Jeff Patton Story Mapping book TBD

XXX Check out Luke Hohmann’s Innovation Games

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.