Reading Time: 5 minutes

What Are Agile Product Roadmaps?

Main Takeaways

Reading Time: 5 minutes In the traditional way, a Product Roadmap states when and which functionality will be released. The Roadmap is aligned with business strategy and release dates. It is a kind of Roadmap, a long-term plan. Instead, an Agile Roadmap is more about communicating our product strategy than it is about communicating features and dates. However, important dates should and could be mentioned, the Roadmap is a statement of intent and direction. The Roadmap visions the certainty and uncertainty of the project/product evolution. It is not a Gantt-chart, or milestone table.

The Difference between Agile Product Roadmaps and Product Roadmaps

In the traditional way, a Product Roadmap states when and which functionality will be released. The Roadmap is aligned with business strategy and release dates. It is a kind of Roadmap, a long-term plan.

Instead, an Agile Product Roadmap is more about communicating our Product Strategy than it is about communicating features and dates. However, important dates should and could be mentioned, the Roadmap is a statement of intent and direction. The Roadmap visions the certainty and uncertainty of the project/product evolution. It is not a Gantt-chart, or milestone table.

“We need to let go of the idea that we can enumerate a list of Features that represents what we’ll do in the future. This idea is absurd.

Rather than sharing Feature lists with the rest of the company, we should be communicating how we will make decisions.

Stop putting Features on your Roadmap. Building products isn’t about Features anyway.

Stop talking to your Customers about Features and start talking to them about benefits instead."

– (Torres 2014)

The Granularity of Agile Product Roadmaps — Sagas, Themes, and User Stories

In Agile and Scrum-like Product Development, the development process is described by so-called Product Backlog Items (PBIs) aka User Stories. A Product Backlog Item isn't a requirement with its specifications. Instead, a Product Backlog Item is a communication scheme to start conversations with stakeholders, and customers/users about the purpose and usage conditions of the features needed.

Over time with the evolution of Agile, a hierarchy of PBIs emerged:

User Stories (the smallest unit),
Epics (collection of multiple user stories),
and Sagas (collection of epics). In some agile terminologies, Themes and Initiatives are synonyms for Sagas, in others, they are larger entities than Sagas. It depends on the agile terminology you use.

All these notions aren't part of Scrum as the Scrum Guide defines. The Scrum Guide only refers to Product Backlog Items.

Sagas, Themes, and Initiatives structure the work areas for your product, they outline the customer/user or business outcome you are trying to achieve. They are not just a listing or grouping of features.
If the Saga description is free of featuring listings and describes outlining the customer/user or business outcome to be achieved, an Agile Product Roadmap shows on the Saga level, how a product will likely evolve over a longer time frame and how the related agile value streams deliver value.

An Agile Product Roadmap is not based on the product backlog but on the product strategy. It contains multiple product goals. It doesn't forecast how a major release or a new product version is developed. A Roadmap isn't a release plan or a burndown chart.

According to Emily Tate (Tate, Lombardo 2018, Aug. 3), an Agile Product Roadmap should consist of the following five components :

Vision: Tells how the Customer/User will benefit when the Product will be fully realized.
Business Objectives: Objectives and Key Results tell what your Product will accomplish, and how it will be measurably different as you fulfil your Agile Product Roadmap.
Timeframes: Timeframes should point to prioritization, and give sequencing and guidance on timing, but should be broad to allow for flexibility. They can show important dates.
Disclaimer: A disclaimer detailing the constraints and the likelihood of change.
Themes / Sagas / Initiatives: Structuring of Work Areas for your Product, outlining the Customer/User or business Outcomes you are trying to achieve. They are not just a listing or grouping of Features.

To fully leverage our Agile Product Roadmap we should avoid the following ten mistakes (Pichler 2022, Nov 1).

The Product Roadmap is a Feature-based Plan. — Drawbacks:
- A Feature-based Agile Product Roadmap can give rise to a Feature-Factory mindset, Product Death Cycle, and Product Build Trap, where adding Features is more important than creating Value and making a positive impact on people’s lives and the business.
- Focussing on Features risks turns the Agile Product Roadmap into a tactical plan that overlaps with the Product Backlog, especially when fine-grained Features are used. This makes the Roadmap harder to understand, and it increases the effort to keep it up to date.
- A Feature-based Agile Product Roadmap is easily mistaken for a commitment rather than a high-level plan that is likely to change. This will not only lead to disappointed Stakeholders. It will also limit your ability to experiment and learn, run sprints and discover the best way to address the User and Customer needs and create Value for the business.
Roadmap Goals are Features in Disguise. — Drawbacks:
- Product Goals are mixed with Features.
- Features describe Product capabilities, they characterise the solution. They do not state why it is worthwhile to progress the Product.
Stakeholders Determine the Roadmap Content. — Drawbacks:
- Individual Stakeholders dictate the Agile Product Roadmap content by wanting to have “their” Features included in the Product.
- Stakeholders' Features don't align with the Product Goal and Strategy. Discuss "wanted" Features by subsuming them to an existing Product Goal, by adding an additional, new Product Goal, or by rejecting them.
The Person in Charge of the Product Creates the Roadmap on Their Own. — Drawbacks:
- It does not leverage the creativity and knowledge of the Stakeholders and development Teams.
- It risks creating a plan that is not clear to the Stakeholders and Development Team members, that lacks a shared understanding, and that causes misalignment.
- People are less likely to support a Agile Product Roadmap if they haven’t had the opportunity to contribute to it. In the worst case, the Stakeholders and development Teams pay lip service to the plan, go off in different directions, and follow their own goals.
The Agile Product Roadmap is Not Systematically Connected to the Strategy and Backlog. — Drawbacks: the Agile Product Roadmap is a plan in its own right, it is a mistake to create and manage it in isolation. This would result in an Agile Product Roadmap that is not aligned with the Product’s Value proposition and business goals and in a Product Backlog that is not linked to the Agile Product Roadmap. This, in turn, can lead to inconsistent and wrong Product decisions.
The Agile Product Roadmap is a Fixed Plan. — Drawbacks: some people mistake the Agile Product Roadmap for a rigid plan that must be executed. But any Roadmap is based on what is currently known. As you start implementing it and learn more about how to best meet the User, Customer, and business needs, the Agile Product Roadmap is likely to change.
The Roadmap is Speculative. — Drawbacks: an Agile Product Roadmap is created by a speculative plan. It is built on wishful thinking rather than empirical evidence. This would most likely result in disappointment and failure.
The Agile Product Roadmap is Overambitious. — Drawbacks:
- An Agile Product Roadmap with unrealistic goals can turn the development effort into a “Death march.”
- The development Team members regularly work overtime, are permanently stressed, and end up being exhausted.
- Creativity, motivation, and Productivity drop, and people’s well-being and health suffer.
- More errors and mistakes occur, and software quality is often compromised making it harder and more expensive to update the Product in the future.
The Agile Product Roadmap is Mistaken for a Release Plan. — Drawbacks:
- The Agile Product Roadmap is the wrong tool for managing development efforts. Development effort is best managed by a Release Plan, e.g., a release burndown chart.
- The Release Plan forecasts how a major release or a new Product version is developed. It doesn't show how a Product is likely to evolve over a longer time frame. This does the Agile Product Roadmap. It is not based on the Product Backlog but on the Product Strategy, and it contains several Product Goals.
The Right Agile Product Roadmap Tool is What Matters Most. — Drawbacks:
- The Team lacked an effective Agile Product Roadmapping approach.
- The Team try to shortcut the Roadmapping process by licensing a powerful tool. They rely on the tool's capabilities more than acquiring relevant knowledge and discovering the right Roadmapping practices.

"Outcome orientation increases the chance of creating value, while output orientation maximizes the odds of delivering crap.
[...] Most roadmaps are the way they are because companies lack the expertise to do it in a better way. Don’t let the status quo limit you. You’ve got a chance to change it."

– (Pereira 2022, Dec 28)