A mechanism for building a roadmap

Peter Pito
Feb 7, 2018 · 11 min read

It is quite common in Agile deliveries for teams to fluctuate between creating no plans to very detailed plans. I found it from experience that these extremes tend to lead to problems in long term.

Having no plans has at least two negative effects: delivery management and clients become very nervous after a while about the delivery, their fear is ever increasing that the project might not deliver what it meant to deliver and will start introducing control measures that are counterproductive long run. Equally, the teams themselves get nervous about the lack of planning and they fear that their future will be full of sleepless nights and working week-ends.

Conversely, creating too detailed plans comes with problems as well. The cost of creating such plans is high, they get out of date as soon as they are created whilst delivering a false sense of confidence. More importantly they can shift the whole delivery model to a plan-driven model, where success is measured whether you are on track against your plan, which is anything but agile.

My typical answer to this problem is “lets build a roadmap”. I came to realise though that at times it might not be enough just to state that, walk away and expect that a roadmap will be built. After all, what actually is a roadmap, and how do you build it? This write-up covers a mechanism of building a roadmap, a mechanism that I have used in deliveries based on both Scrum and Kanban. I must stress though that I don’t believe that this is the only way to do it, I’m not creating a ‘method of building roadmaps’, but I hope that some will find this mechanism a good starting point in their journey of building roadmaps.

Image for post
Image for post
“We have another chance to navigate, perhaps in a slightly different way than we did yesterday. We cannot go back. But we can learn.” Jeffrey R. Anderson

I choose to call this write-up a mechanism because I focused on the constituent parts of the roadmap and how they are connected, glued together. The constituent parts of how they are connected together is not fixed, how you determine the parts is your call. For instance, I will be talking about prioritisation — for this aspect of the roadmap you can apply anything from gut feel, to weighted shortest job first, to cost of delay divided by duration, etc.


The creation of a roadmap is a modelling exercise. The aim is to build a model that represents the reality. The closer the model is to reality, the less of a calibration is needed.

To understand what we are modelling one of the first questions to explore is what are we doing, who are we? Are we building one product, or a platform that hosts multiple products? I tend to represent this model graphically, show it to team members and external stakeholders for review and challenge. The process of review helps refining the model and build a common language along a way that will be carried across the roadmap and beyond. For instance, we could end up with ‘we are a digital platform building multiple applications and providing infrastructure capabilities. We see each application and capability as a product, and this is what we’re going to model’. It is important to build this shared vocabulary to understand in our context what is a platform, or a product, or a feature, etc.

Image for post
Image for post
Visualise the world that you about to model

Unit — finding the right granularity for our model

Once we know what we are modelling at high level it is useful to assess whether the granularity we have identified so far is good enough for the purpose of modelling the roadmap.

For instance, if we decided that we are building a product then what is the level of granularity that we want to model? Is it the product per se as one unit, or the building blocks of the product (subsystem, modules, features, etc)?

Finding the right level of granularity is important to make the roadmap useful, actionable. If the granularity of the model is too coarse grained then we end up with big blocks of work that can span across multiple months. This tends not to be very useful to work with since this reduces the flexibility of planning and offers little actionable insight into what is happening. For instance, all we can state for long periods of time is that we are working on something (i.e. ‘we are building a mobile shopping application’). If the granularity is too fine grained then the roadmap will be full of too many details, which in turn will create too much noise and will make the roadmap unusable (for instance if the roadmap is made up of all the user stories the teams build).

Finding the right level of granularity is closely linked to your decomposition strategy of the scope, which is your strategy of slicing, grouping and classify the scope.

To achieve this decomposition a number of techniques can be applied, such as Jeff Patton’s ‘User Story Mapping’, Simon Wardley’s ‘Wardley Maps’ and Gojko Adzic ‘Impact Mapping’.

Image for post
Image for post
Wardley maps can be used to decompose our scope.

The decomposition strategy of scope is one the most important aspects of building the roadmap. However, since this write-up is about the roadmap mechanism I am not going to detail this aspect. The above example is a Wardley map that can be used in isolation or in conjunction with other techniques to get to the bottom of how we slice and dice our scope.

Once the right level is found then we use the elements at this granularity in a roadmap. For the purpose of this write-up I will call them features, the things that we want to deliver (a collection of items that are related together — e.g. Shopping basket), but these could be modules, or subsystems or components.

Image for post
Image for post
Group together your building blocks to match what you are building. In this example, features are closely aligned to the products the team are building. Visualise it.


In an ideal world, the capacity of a delivery team would be big enough to react to and build every feature as the demand arises. However, that is never the case, therefore we need to make trade-offs between what we build and what we defer. We can treat all the demands/requests as options, things that we might end up doing. It is useful to keep these options open for as long as possible, avoiding committing to them just in case something more valuable to build would turn up.

The demand for options can come from multiple sources, such as:

Treating features as options comes with a number of advantages.

First of all, if a demand is passed onto us we can clearly state at point of acceptance that it is only an option. Quite often when someone is passing on a request to us and we accept it they would assume that we committed already to build it. We want to separate the commitment point, and using the term option is a very simple way of clarifying what we doing.

Secondly, we can apply Real Options principles [1] to our backlog:


Options will expire at one point, therefore it comes a time when we will need to make commitments to build or not. This is an important ceremony in the construction of a road-map, and as stated above our clients, as well as our team will need to understand the distinction between an Option and a Committed features.

Image for post
Image for post
Visualise what feature is an Option vs a Commitement


This is typically the hardest part in building a road-map. Since most of the time the demand for options outweighs the capacity of the team we need to decide what to build in what order (priority). Also, we need to decide whether we build sequentially or in parallel (mode of build). To make matters more complicate, the mode of build can and change in time.

“The problem with any prioritization decision is [the] decision to service one job and delay another” — Don Reinertsen

To determine the priority of our options, we can choose multiple techniques, anything from gut feel to elaborate economical models.

We can choose to use the same technique for all our features, or as suggested by Troy Magennis we can use the technique that is appropriate for the level of negative impact should we get the decision wrong[2].

Based on how we determine the value of a feature Troy suggests that we can use a sliding scale to select a technique, from a subjective to a more deterministic approach. As we ‘move to the right’ of this sliding scale we take into consideration an ever increasing number of factors in evaluating the value. The scale goes from relying on HiPPO (Highest Paid Person’s Opinion) to ‘just make a choice’ to economic models such as Weighted Shortest Job First [3]. If the risk of getting it wrong is low, HiPPO might be just good enough.

Once we have determined the priority, we need to determine the mode of build (sequential or parallel). As tempting as it is to build many features in parallel, this is not always a good idea. When selecting which options we build in parallel we should take into consideration a number of factors, such as:

If we see our delivery as one queueing system, where items enter as ideas and depart as working software, then one of the most powerful way to reduce the cycle time (the time it takes an item to traverse our system) is to limit the work in progress (WIP) at macro level, at road-map level. And we can do that by choosing how many feature we want to work in parallel.

Quite often limiting of work in progress happens at lower levels (i.e. at story level), which is useful and should be still done. However, limiting at macro level is more impactful. Using the roadmap which shows the high-level view, leaders can guide teams to improve their focus by helping and supporting the reduction of number of features worked on. This will reduce WIP and improve cycle time.

Image for post
Image for post
Limiting the WIP at feature level can drastically reduce the workload of the team, helping them focus on fewer work items.


To build features and chase the value delivered by those features we need capacity. This is the capacity of the team doing the work. The capacity can fluctuate depending on many factors.

Image for post
Image for post
Capacity of the team can be split on working on multiple feature. There are a number of factors that influence the capacity, unplanned work being one of them.

Capacity is useful to calculate and particularly important if we choose a method of prioritisation that takes in consideration the cost/duration of the feature to be built. For instance, if we use a Cost of Delay Divided by Duration (CD3) [4] technique then we need to understand what is the capacity of our team to determine the duration of the feature.


In the journey of building the roadmap for each feature we tend build in a number of assumptions. If these assumptions turn out to be untrue, then the whole roadmap can be significantly impacted.

The best way to mitigate these assumptions is to capture them and share them as widely and as soon as possible. The hope is that some-one will say ‘Oh, that won’t work’ as early as possible when the cost of recovery (or change of plans) is still low.


For each feature in our roadmap there is a likely list of uncertainties. Some will have bigger impact than others if they materialise. It is useful to create a map with the team and stakeholders to identify those uncertainties along with their impact. The goal here is to focus efforts first on the items with the bigger impact and higher likelihood of materialising.


Those dreaded dependencies that can slow you down are part of the roadmap. You can use both the roadmap to avoid dependencies (by using it as a tool to schedule work in order to reduce dependencies), as well as when this is not possible to visualise them.

Putting it all together — the output of the road-map

Having all the building blocks now we need to put it all together. We need mechanisms to both build the roadmap as well as communicating it to our teams, stakeholders and clients.

Things that we should consider while building and visualising the roadmap are:

Answering those questions can be the topic of a write-up on its own. What I will add though in this entry is that I found it in practice that you might need multiple artefacts to build and communicate the roadmap.

For instance, the list of artefacts could contain:

Image for post
Image for post
Kanban view of the roadmap. Highlight the commitment point when you turn the Options into Commitments.
Image for post
Image for post
Output of a road-map. You can use swim-lanes to show the life-cycle of a product. Releases visualised vertically representing a snapshot of all your features delivered up to that point. Note that longer term features are less certain and can be captured as simple bullet points.

The timeline view of the roadmap can take different forms, some more useful for our teams, some more useful for our clients and stakeholders.

Image for post
Image for post
Alternative view on visualising the roadmap. Releases become swim-lanes bunching together products and features that will make up a release.

A living thing

The road-map is a living thing, demands and capacity change in time influenced by a multitude of factors. Whenever new information is surfaced that impacts the roadmap then this needs to be reflected and continuously socialised. It is very useful if the cost of building the roadmap is low to achieve this.

Get the mechanism of building a roadmap right and will become an indispensable tool in your journey.

Thanks for my work-colleagues for providing feedback on this write-up, especially to Poddy.



Sign up for Get Better Tech Emails via HackerNoon.com

By HackerNoon.com

how hackers start their afternoons. the real shit is on hackernoon.com. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Peter Pito

Written by

Agile practitioner and software developer at heart. Husband, father and rookie triathlete. I try to be the best version of myself, as often as I can.


Elijah McClain, George Floyd, Eric Garner, Breonna Taylor, Ahmaud Arbery, Michael Brown, Oscar Grant, Atatiana Jefferson, Tamir Rice, Bettie Jones, Botham Jean

Peter Pito

Written by

Agile practitioner and software developer at heart. Husband, father and rookie triathlete. I try to be the best version of myself, as often as I can.


Elijah McClain, George Floyd, Eric Garner, Breonna Taylor, Ahmaud Arbery, Michael Brown, Oscar Grant, Atatiana Jefferson, Tamir Rice, Bettie Jones, Botham Jean

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store