A mechanism for building a roadmap

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.

“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.

Model

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.

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’.

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.

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.

Options

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:

• clients
• our team
• other teams part of a program
• wider company
• etc.

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 are 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 are doing.

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

1. Options have value
2. Options expire
3. Never commit early unless you know why

Commitment

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.

Visualise what feature is an Option vs a Commitement

Scheduling

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:

• is there an advantage to build in parallel, especially closely related features, or is it better to build something, test it and continue only if the sign of success are positive?
• what is the ability of our delivery teams to develop in parallel?
• what is the impact on the overall timelines if we are building in parallel? Building in parallel too many dependent features that have not been well decomposed can, and likely slow down the overall delivery.

If we see our delivery team 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.

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

Capacity

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.

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.

Assumptions

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.

Uncertainties

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.

Dependencies

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:

• how and where do we store our options?
• how do we communicate to our requestor that when we got the request it was only an option? How do we communicate that we have turned that option into a commitment? Or, when we had to abandon a commitment (not nice, but can happen).
• how do we order the options? Who does it and do we communicate the outcome, remembering that likely this process will be frequent?
• how do we communicate the changes in our committed features?
• how do we communicate when features will be available so that those who need them can start using them?

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:

• a scope decomposition view showing the features that will form part of the roadmap
• an ordered list of features along with a short description, source of demand, prioritisation inputs (such as cost of duration, cost of delay if available), assumptions
• a Kanban view showing how those features traverse your system, the macro WIP

Kanban view of the roadmap. Highlight the commitment point when you turn the Options into Commitments.

• a timeline view showing how and when those features will be released

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.

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.

[1] https://www.infoq.com/articles/real-options-enhance-agility

[2] https://github.com/FocusedObjective/FocusedObjective.Resources/blob/master/Canvas%20and%20Forms/Better%20Backlog%20Prioritization.pdf

[3] Don Reinertsen, Principles of Product Development Flow

[4] http://blackswanfarming.com/cost-of-delay-divided-by-duration/

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

A mechanism for building a roadmap was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.