Step 6: Roadmap

This chapter describes the sixth step in the framework, detailing how to create an actionable plan based on all the previous steps, called a roadmap.

Step 6: Roadmap – Creating an actionable plan (roadmap)

The roadmap is a key element to communicate our product’s future and to reach alignment, inwards (teams) as well as outwards (stakeholder). It is the major baseline that everyone else will reference. Thus, the roadmap should always be up to date, transparent and available to all people involved. The roadmap is regularly updated within the roadmapping meeting. (See Roadmapping meeting)

As the last step before delivery, the roadmapping step is a sum of all previous steps in the framework. It shows why we are doing it (strategy & vision) as well as a plan on how to achieve it.

To create a meaningful roadmap, on top of all the information from the previous steps, three additional bits of information are needed:

  • Team capacity
  • External dependencies to be managed
  • Important dates/milestones

Team capacity means how much “workforce” is available over time. In an ideal world, this is a flat line, with a constant capacity – but on many occasions it isn’t, which is why it has to be part of the plan. It is represented by a line, showing the available capacity over time. (Shown in blue in the following schematic)

External dependencies can have a big impact on delivery dates. Which is why they have to present on the roadmap and made transparent, so they can be managed. For example: A specific opportunity might need legal approval before starting development, or there is a technical dependency on another product within the company. Managing these has to be the primary responsibility of the product manager/product owner.

Important dates/milestones can be dates for releases (like the MVP), specific trade fairs or any other important date, where a specific state of the product is expected to be available.

The following schematic shows how all this information comes together in one visual picture.

Note that at the top, the condensed strategy and vision elements from Step 1: Vision are present. These act as anchors, ensuring, that while diving deep into roadmapping details, the overarching vision and goals are fulfilled.

Serving our two core ideas of transparency and alignment, the roadmap should be made transparent and shown as often as possible to stakeholders and teams. This enables self-managing agile teams, being able to take effective decisions on a day to day basis, while staying true to the overarching plan/strategy.

Blocks of work

The y-axis in the schematic above has to represent a meaningful metric of our agile delivery method. Depending on the agile delivery method used, there is at least one major metric, measuring (and predicting) how much the team(s) can deliver. In Scrum, this would be velocity (based on story points), in Kanban, this would be cycle time (based on number of work-items).

Let’s say we are using scrum, and story points. Let’s assume that, in our previous step, the first opportunity (“Opportunity A”) was estimated to be 24 story points in size. We decide that 8 is a meaningful scale on our Y-axis, thus “opportunity A” would be represented by 3 blocks (each worth 8 story points).

This is just a visual representation of the estimated work. These are not user stories on a wall or descriptive items. Just blocks, visualizing the amount of work. The advantage of this is, that it can be easily understood and even more important, easily changed. Staying true to our core idea of product agility, we have to embrace change, and thus require a planning method, that can quickly adapt to changes. As new things are learned during delivery, estimations and requirements always change. The block method allows us to visually grasp the amount of work and allows us to easily rearrange items during daily delivery routine and quickly grasp where changes might be needed.

Agile metrics and agile leadership

Agile planning relies on accurate agile metrics. That means, it is vital that the agile metrics collected are reliable. If these are 300% off from reality, our plan will also be 300% off from reality.

It is the responsibility of the product owner/product manager to lead their teams to supply these metrics with a reliable accuracy – Of course this can happen with the help of agile coaches/Scrum Masters, but setting the requirement and leading the teams to quality metrics is part of agile leadership that product owners/managers have to ensure.