What Is an Agile Roadmap?

At its simplest, an Agile Product Roadmap gives an overview how a product's development will  likely evolve over time. It's a tool that allows you to communicate the team's current thinking around what they'll build and how they're planning to reach their product vision

However, that's hiding the true power and importance of an Agile Roadmap.

How an organization approaches a Product Roadmap is a key indicator of whether their Agile implementation will be full of pain and frustration, or allow them to soar above the competition and establish market dominance.

To understand why, we need a brief diversion to look at the first line of the Agile Manifesto.

"Individuals and interactions over processes and tools."

This simple line is the reason most organizations fail on their first Agile implementation. (And their second. And quite probably, their third and fourth too.)

Organizations create a roadmap, and then forget about it. It gets put in a drawer with no cadence to revisit it and adjust it with the right people.

Having a Roadmap is not the important part. The individuals and their interactions as they create the Roadmap is what matters. 

Of course, this isn't a new concept.

A true Agile Product Roadmap is created after an Agile team has established their vision. The Roadmap is the plan to get to that vision or North star.

Why Use an Agile Roadmap?

The Roadmap gives the strategic overview of the product, meaning there needs to be clarity from the stakeholders on the goal and priorities.

As the Roadmap planning starts, the priorities force the team to focus on what matters. At this point Product owners have a decision to make.

Do they direct the team, or allow the team to make the decisions? Directing without buy-in will give you a team that'll do the work. They'll turn up, code, moan there are too many meetings and the project will take twice as long as predicted and cost twice as much as planned. 

The alternative is to generate buy-in from the team. They’ll still moan there are too many meetings, but they’ll care, be excited, and want to perform. They’ll follow your vision and engage. 

By allowing individuals to have freedom and interact, they'll start to build a consensus on how to proceed. This is the first step in generating genuine buy-in. 

As individuals in the team buy-into the project, they take responsibility and hold each other accountable to deliver. When decisions need to be made, as long as the vision and success metrics are clear, their commitment to the product and the long-term vision of that product and to each other ensures they remain focused and driven to succeed.

This brings us to the mistakes organizations make with Agile that makes adopting it so challenging.

Mistakes Organizations Make When Creating an Agile Product Roadmap

The whole point of Agile is that we retain the ability to pivot. We put something out to production, or show our stakeholders what we’ve built. We get feedback, and make changes based on that feedback.

By definition, receiving that feedback is going to change our roadmap plans almost every time.

Agile Roadmaps are not contracts

The mistake most organizations make, especially when moving from traditional mindset to an Agile mindset, is that they treat Roadmaps as commitments. Agile Roadmaps are not contracts. They’re going to change. 

Executives and leaders often fail at this hurdle. They’re used to a Roadmap being something they’re committing to for at least the next six to twelve months. They put the Roadmap in a drawer, then magically, six months later, they bring it out and judge the team on it. Did you do all the things on the list?

That’s the wrong way to approach a Roadmap. A better question for them to ask may be, “Did we move the needle on the things that are most important? What were the outcomes we created for our customers?” Roadmaps are NOT commitments.

Believing you know what you need in nine months from now

Any leader would love to predict what they need to deliver nine months from now. However, that’s impossible for two key reasons.

First, technology changes too fast. Developers discover new ways of using it and it evolves continuously. What’s best practice now may be obsolete in weeks.

Second, customers think they know what they want, but often don’t realize what they really need until they’ve got the wrong thing in front of them (that they might have asked for), so the requirements change as the product is created and feedback received. 

This makes it impossible to make the right decisions now for what’s needed in the future. A true Agile organization is able to pivot and quickly move based on learning. 

The better perspective is to consider, “Would you rather have persistent stable teams that can make frequent pivots and deliver what is most valuable today?”

That’s the game changer. It also addresses how to consider the budget for an Agile Team.

The budget is focused on the wrong thing

In a traditional organization, you fund the project that you’re building. It’s always been done this way and leaders understand it. However, because it’s impossible to predict what they need to deliver nine months from now it no longer works.  Scope creep often ends in runaway projects.

When organizations fund big projects, we almost always cut scope at the end, or extend the time-frame. The impact is either unhappy customers or significantly delayed projects and value.

By funding stable teams who have a stable set of products, they are able to make decisions about how to evolve the product or products as they’re closest to the customers and can help the Product Owners define priorities.  Trade-offs are made about date or scope, but because the team is persistent, those trade-offs don’t have far reaching impacts across the organization.

The good news is that the solution to Agile budgeting is simple. Fund the knowledge workers, the Agile teams. Then the budget is simply the run rate of the team. It’s very stable and therefore predictable. This allows organizations to move the work to the people, instead of the people to the work. It’s a simplified budgeting model, however, those who make their living by “moving resources around” can be very resistant to it.

You can still get an ROI on projects, however, the focus becomes how to funnel the most important work to which team.

This definitely isn’t an overnight change. This type of funding model only changes after enough momentum has built up, however, it is necessary in order for autonomous Agile teams to be created.

You don’t match demand to capacity

Another mistake is that organizations don’t match demand to capacity. To do this accurately, we need to have some ability to estimate and prioritize using some form of economics. How do we know that not only are we delivering the right things next, but that they actually fit our capacity?

This brings in a whole new series of estimating and prioritization. The ability to match demand to capacity is key for success.

We can give immediate insight into how to achieve this by reviewing any existing data around the team’s velocity, their capacity. This historical data enables us to understand the organisational capacity in the past and use that to predict the future and, using estimation, we can begin to match the two and create realistic plans of what the organization could achieve.

All teams are similar

Another mistake commonly made is to assume all teams are similar. A SAFe team often commits to a quarter’s worth of work because of dependencies and aligning with other teams, yet that’s not always going to be true for singular teams. They often have more flexibility as they can deliver on their own so it may be acceptable to commit to one sprint at a time. Similarly, if they’re scaled, they may be able to commit a little further out as they have a lot of dependencies.

It’s back to the fact that the Agile journey is different for different teams and it’s crucial to understand where your team is and how well your Agile team is performing. 

Too many Agile Roadmaps

It is tempting to have more than one project roadmap, however this quickly creates a situation where there's one for the scrum master, one for the external stakeholders, a technology roadmap, and an internal roadmap too. Having multiple roadmaps dilutes the strategic themes and ultimately makes life overly complicated for the Product Manager. Trying to sync them is time-consuming and becomes impossible to manage.

The ideal solution is to write a product roadmap with the customer, from their perspective, from the beginning. Then, add in a couple of technical items, your enablers, for the product team. This way you have a single master plan that everyone is working off.

The Perfect Agile Roadmap (doesn’t exist)

Product Roadmaps need to be transparent and visible. Anybody should be able to see it. Teams should have access for their roadmapping.

However, it’s a stumbling block that people like to hold onto them. They show executives once a quarter and the team feels like, “I have no idea what we’re doing. All I know is what I’m doing the next sprint.”

The reasons this happens is entirely understandable. The Product Owner wants it to be perfect before they show it to anybody.

In reality, it should be, “Here’s what we know right now. And we know it’s going to change.”

Unfortunately, the very real concern is around how others might interpret the plan and use it against them or the team.

A major part of coaching teams is to help them understand why it’s important to broadly communicate and that transparency is critical. Transparency for Agile allows the organisation to adapt, and that requires a team to think beyond just what's important for the team, but apply system thinking towards the whole organisation.

The Agile Roadmap isn’t frequently updated

The Product Owner or product management is the content authority of the Roadmap. They should be responsible for updating the Roadmap and establishing the cadence around how frequently the team should revisit it. Our usual guidance is to establish a six to nine month horizon and, as each month passes, to add a month so there is always at least six months planned out.

Sometimes, if it’s a brand new product, you may go a little further out as there will be architectural and technical considerations. If you’re simply evolving something, taking a product and enhancing it, six months usually works very effectively.

How To Create a Agile Product Roadmap

The difference between Precision and Accuracy in product roadmaps

A Roadmap has a key role in confidence around a project. The closer we are along the roadmap, the more confidence we have about where it’s going. The confidence is a balance between precision and accuracy.

For example, a SAFe team may say that for the next three months, we know exactly what we’re focused on, as we’ve committed to those objectives and planned it and we understand what we’re delivering - this is both accurate and precise. Beyond that it’s forecasting.  

Looking further away, the next quarter, we’ll have more of a “medium” level of confidence. We’ll have “thrown some stuff at the wall” yet won’t have received any feedback other than maybe our stakeholders have given us a thumbs up.

And beyond that, we simply need to make sure we have the right level of insight so that whatever decisions we make, we don’t create constructs that create problems such as architectural type of work.  This is directionally accurate, but not precise.

Many organizations, if they don’t have a Roadmap, make decisions today without that forward-looking thinking, and find themselves at a point where they cease to be able to pivot because they didn’t start with the end in mind.