AoAD2 Practice: Roadmaps

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 15, 2021


Product Managers

Our stakeholders know what to expect from us.

Ultimately, accountability is about providing good value for your organization’s investment. In a perfect world, your business stakeholders will trust your team to do so without close supervision. This is achievable, but it usually takes a year or two of delivering reliably first.

Stakeholder Trust
Stakeholder Demos

In the meantime, your organization is going to want to oversee your team’s work. Stakeholder demos help, but managers often want to know more about what you’re doing and what to expect. You’ll share this information in your roadmap.

Agile roadmaps don’t have to look like traditional software roadmaps. I’m using the term fairly loosely, to encompass a variety of ways that teams share information about their progress and plans. Some roadmaps are detailed and to the point, for sharing with managers; others are high-level and glossy, for sharing with customers.

Agile Governance

The type of roadmap you provide dependence on your organization’s approach to governance. How does your organization ensure teams are working effectively and moving in the right direction?

The classic approach is project-based governance. It involves creating a plan, an estimate of costs, and an estimate of value. The project is funded if the total value sufficiently exceeds the total costs. Once funded, the project is carefully tracked to ensure that it proceeds according to plan.

This is a predictive approach to governance, not an Agile one. It assumes that plans should be defined in advance. Change is carefully controlled and success is defined as meeting the plan. Management needs roadmaps that include detailed plans, cost estimates, and completion progress.

The Agile approach is product-based governance.

The Agile approach is product-based governance. It involves allocating an ongoing “business as usual” budget and estimating the value the team will produce over time. The product is funded if the ongoing value sufficiently exceeds the ongoing costs. Once funded, the product’s value and costs are carefully monitored to ensure it’s achieving the desired return on investment, independent of the actual features delivered. When the value is different than estimated, costs and plans are adjusted accordingly.

This is an adaptive approach to governance. It assumes that the team will seek out information and new opportunities, then change their plans to take advantage of what they learned. Success is defined in terms of business results, such as return on investment. Management needs roadmaps that include spending, value metrics such as revenue, and a business model.

Although Agile is adaptive, not predictive, many Agile teams are subject to project-based governance. Your roadmaps need to accommodate this reality. I’ve provided four options, from maximally adaptive to maximally predictive. Choose the lowest numbered option you can get away with. In some cases, you’ll have multiple roadmaps, such as one for management oversight and one for sales and marketing.

You can present your team’s roadmap in whatever format you like, and to any level of detail. For internal roadmaps, a small slide deck, an email, or a wiki page are all common choices. For externally-shared roadmaps, a glossy, less-detailed web page or marketing video are common.

Option 1: Just the Facts

A “just the facts” roadmap isn’t a roadmap at all, in the traditional sense of the word. Instead, it’s a description of what your team has done so far, with no speculation about the future.

From an accountability and commitment perspective, this is the safest type of roadmap, because you only share things which have happened. It’s also the easiest to adapt, because you don’t make any promises about future plans. It includes:

  • Your team’s purpose.

  • What’s complete and ready for your next release.

  • Your next release date, if you’re using pre-defined release dates. (See “Predefined Release Dates” on page XX.)

Additionally, for management roadmaps, Optimizing teams will include:

  • Current business value metrics (revenue, customer satisfaction, etc.)

  • Current costs

  • Business model

Even if management needs a more predictive roadmap, a “just the facts” roadmap can work well for sales and marketing. The advantage of the “just the facts” approach is that no one is ever upset when your plans change, because they don’t know your plans have changed. Combined with a release train (see “Release Early Release Often” on page XX), this can lead to a regular announcements of exciting new features that people can have right now.

One well-known example of this approach is Apple, which tends to announce new products only when they’re ready to buy. It’s also common in video games, which use regular updates accompanied by “what’s new” marketing videos to re-energize interest and engagement.

Option 2: General Direction

Stakeholders often want more than just the facts. They want to know what’s coming, too. A “general direction” roadmap strikes a good balance. Speculation is kept to a minimum, so your team can still adapt its plans, but stakeholders aren’t kept entirely in the dark about the future.

The roadmap includes everything in the “just the facts” roadmap, plus:

  • The valuable increment the team is currently working on, and why it’s the top priority.

  • The valuable increment (or increments) most likely to be worked on next.

The increments are presented without dates. Optimizing teams might also include hypotheses about the business results of upcoming releases.

Option 3: Date and Approximate Scope


A “date and approximate scope” roadmap adds forecasted release dates to the “general direction” roadmap. This reduces agility and increases risk, because people tend to take these sorts of roadmaps as commitments, no matter how many caveats you provide.

That leaves teams with an uncomfortable tradeoff: either you use a conservative forecast, such as one with a 90% probability of success, and provide a pessimistic release date; or you use a more optimistic forecast, such as one with a 50% probability of success, and risk missing the date. Furthermore, work tends to increase to fill the time available, so more conservative forecasts are likely to result in less work getting done.

However, because the roadmap doesn’t include the details of each increment, the team can still steer its plans as described in “Predefined Release Dates” on page XX. Rather than forecasting when every story will be done, make a conservative forecast for the “must have” stories in your plan and treat it like a predefined release date. This will give you a forecast you can meet without being too far in the future. Then, if you end up with extra time—and, if the forecast was truly conservative, you usually will—you can use that time to add polish and other “nice to have” stories.

Optimizing teams usually don’t use this sort of roadmap. The business cost isn’t worth the benefit. However, it can be useful when they need to coordinate with third parties, such as for a trade show or other marketing event.

Option 4: Detailed Plans and Predictions

This option is the least Agile and has the greatest risk. It’s a “date and approximate scope” roadmap that also includes every story in the team’s plan. As a result, the team can’t steer its plans without having to justify their changes. This results in more conservative forecasts—meaning more potential for wasted time—and less willingness to change.

Although this is the riskiest type of roadmap, organizations tend to prefer it. It feels safer, even though it’s actually the least safe approach. Uncertainty makes people uncomfortable, and this roadmap allows them to speak with certainty.

Artificial certainty just makes adapting to changing circumstances more difficult.

That certainty is an illusion, though. Software development is inherently uncertain. Artificial certainty just makes adadpting to changing circumstances more difficult.

Sometimes you have to provide this roadmap anyway. To do so, make forecasts that include every story, not just the “must-have” stories. As with option 3, you’ll need to decide between conservative forecasts, which are reliable but potentially wasteful, and more optimistic forecasts, which you could fail to meet.

Teams without Focusing and Delivering fluency typically have a lot of risk, which means that a properly conservative forecast will show a release date that’s too far in the future for stakeholders to accept. You’ll typically have to use a less conservative forecast, even though the date is more likely to be missed. One way to work around this is to only forecast near-term releases, if you can. “Reducing Risk” on page XX has more details.

Optimizing teams don’t use this type of roadmap.

Corporate Tracking Tools

Tracking teams with planning tools is a mistake.

Companies will often mandate that their teams use a so-called Agile lifecycle management tool, or other planning tool, so they can track teams’ work and create reports automatically. This is a mistake. Not only does it hurt the team—which needs free-form visualizations that they can easily change and iterate—it reinforces a distinctly non-Agile approach to management.

Stakeholder Demos

Agile management is about creating a system where teams make effective decisions on their own. Managers’ job is to ensure teams have the information, context, and support they need. “Agile” planning tools are anything but Agile: they’re built for tracking and controlling teams, not enabling them. They’re an expensive distraction at best. Don’t use them. They will hurt your agility.

That doesn’t mean teams have no guidance. Management still needs to keep its hands on the wheel. But this is done by iterating each team’s purpose, providing oversight and feedback during stakeholder demos, and using the most adaptive roadmaps possible, in addition to effective and engaged team-level management.

If your team is required to use a corporate tracking tool, only enter the information required by management. Use the other planning practices described in this book for your day-to-day work, copying information into the tool when needed. If your roadmap only includes valuable increments, not stories, this won’t be too much of a burden.

Visual Planning

If you have to include stories in your roadmap—which I don’t recommend—see if there’s a lightweight way you can do so. Perhaps you can take a picture of your visual plan rather than transcribing the cards into a tool. Perhaps managers should be more involved in planning sessions, or perhaps they’re asking for something they don’t actually need.

If they insist, though, you can transcribe stories into a corporate tracking tool. Do it once per week—or daily, if you have no other choice—and remember each story should only be a short phrase, not a miniature requirements document.

If managers need you to maintain more detail in the tool, or insist on tracking individual tasks, something is wrong. Management may be having trouble letting go, or your organization may not be a good fit for Agile. Ask a mentor for help.

When Your Roadmap Isn’t Good Enough

Eventually, somebody is going to ask you for a roadmap with a date forecast, then tell you that you the forecast is too far away and you need to deliver sooner.

Cutting scope is the only sure way to deliver sooner.

There is only one sure way to deliver sooner: cut scope. You have to take stories out of your plan. Everything else is wishful thinking.

You can try improving your capacity (see “How to Improve Capacity” on page XX) or further developing fluency, but start by cutting scope. Those other efforts take time, and their impact is hard to predict. If they pay off, you can put the cut stories back in.

Sometimes, you won’t be allowed to cut scope. In this case, you have a tough choice to make. Reality won’t bend, so you’re stuck with political options. You can either stand your ground, refuse to change your forecast, and risk getting fired; or you can use a less conservative forecast, provide a nicer-looking date, and risk releasing late.

Before making that decision, look around at the other teams in your company. What happens when they miss their dates? In many companies, release dates are used as a bludgeon—a way of pressuring people to work harder—but have no real consequences. In others, release dates are sacred commitments.

If you’re trapped in a situation where your roadmap isn’t good enough and you don’t have the ability to cut scope, ask for help. Rely on team members who understand the politics of your organization, discuss your options with a trusted manager, or ask a mentor for advice.

Remember, whenever possible, the best approach to forecasting is to choose a predefined release date and steer your plans to meet that date exactly.


How often should we update our roadmap?

Stakeholder Demos

Update it whenever there’s substantive new information. The stakeholder demo is a good venue for sharing roadmap changes.

What should we tell our stakeholders about forecast probabilities?

In my experience, forecast probabilities are hard for stakeholders to understand. I provide a range of dates, but don’t go into detail about probabilities.

If teams don’t report their detailed plans, how do team-level managers understand what their teams are doing?

Team-level managers can look at their team’s planning boards directly. See “Management” on page XX for more about managing teams.


Anybody can create roadmaps, but creating effective, lightweight roadmaps requires Agile governance and a willingness to allow teams to own their work, as discussed in chapter “Invest in Agility”.


When you use roadmaps well:

  • Managers and stakeholders understand what the team is working on and why.

  • The team isn’t prevented from adapting their plans.

Alternatives and Experiments

There are many ways of presenting roadmaps, and I haven’t gone into details about specific presentation styles. Experiment freely! The most common approach I see is short slide decks, but people also create videos (particularly for “just the facts” roadmaps), maintain wiki pages, and send status update emails. Talk with your stakeholders about what works for them.

As you experiment, look for ways to improve your adaptability and make fewer predictions. Over time, stakeholders will gain trust in your team, so be sure to revisit their expectations. You may discover that previously set-in-stone requirements are no longer important.

Further Reading

XXX Johanna Rothman? Pat Reed?

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.