Join the Mastering Agility Discord community!
This article continues from the Product Wall introduction article. These series are co-written with Ryan Brook based on our upcoming book. You can download our free Product Wall Mural template here.
Now we have covered the general overview of the entire Product Wall, we break it down piece by piece. In this article, we explain the Roadmap section. Let's define what it is, and also what is not.
A roadmap is: a tool to create transparency around the vision, direction, progress, and order of the Product. It may change through the whole development lifecycle. It's a high-level, strategic plan around what is likely to be done in the future of development.
A roadmap is not: a fixed list of promises that teams need to deliver during the next year so management can base their budget on that and punish the team if they haven't met their roadmap. If that is what you are looking for, please close your laptop and never look at this article ever again.
Having clarified this, roadmaps can prove to be a very useful way of provoking discussion on what to do when, how they can affect releases, and what the order in the Product Backlog might be. There are many types of roadmaps, including:
- Now, Next, Later
- Goal Oriented Product Roadmaps
- Story Maps
- Feature List Roadmaps
- The Visual Product Roadmap
For this example, we will stick to the "Now, Next, Later" one, as it is both easy to use, as well as easy on the eyes.
There are a few elements:
General product information: it lists information like what product is being developed, what team is working on it, and the number of the Sprint. Of course, this is just an example, you can augment it with whatever you like. Think of elements like date, update version, link to stakeholder mapping, where to find the Product backlog, etc. It might be a good idea to refer to the Product Vision somewhere on the Product Wall, so that everything that is on the Roadmap can be linked to the achievement of this vision.
Not a focus: for the sake of transparency, you can list ideas or concepts that have been brought in by stakeholders, but that are currently not important or critical enough to be developed or planned to reach Product Goals.
And, as may not be a surprise, the actual Now, Next, Later elements: What is our current focus? What are we likely to work on in the next one or two Sprints? And what may we be working on after that? There are certain Product Backlog Items in our example, with some very high-level action items that can be things like dependencies or impediments that need to be taken care of (no, not by the Scrum Master per se. Anyone can remove dependencies, the Scrum Master causes the removal of impediments but doesn't have to resolve them on their own). Note how these items contain ample details. This is done for a reason - to cause conversations with the relevant stakeholders. Y'know, Individuals and Interactions over Process and Tools. Something, something, agile manifesto. Conversations are where potential value is discovered, and delivery and measuring are what validate the assumptions in our roadmaps.
These items are, like the Product Backlog itself, open to be reshuffled. You can even add connection lines between items, or do some color coding, to visualize dependencies or relations between items.
Beyond Now, Next, Later
There might be more to the Product Backlog that is covered by the Now, Next, Later roadmap. Or there may be some organizational requests to create (an arguably false sense of) certainty about what will be delivered in the coming 18 months. Think about something along the lines of:
- H1 Business as Usual
- H2 Sustaining Innovation
- H3 Disruptive Innovation
Both Ryan and Sander work as consultants, so we realize that theory and practice are two vastly different things. We appreciate the desire to know what is going to happen at the end of the year, or beyond that. We would love to know ourselves, too. Do you know what you will be eating exactly in the coming six months? We are confident you don't. Let's be honest, no one knows what the future holds, so making a budget based on things that will probably not be correct, is nothing short of setting yourself up for disappointment.
We would recommend experimenting with releasing funding based on outcomes that are created in the coming three Sprints or months. Did we achieve what we hoped we would? Then let's see what we can learn from that, have a look at our Roadmap, and see how much funding we need for the coming period. By adding this dimension to your Now, Next, Later Roadmap, it is less of a surprise what the expected investments are looking ahead, and maybe even what the ROI has been looking back. Makes certain discussions quite a bit easier.
Write with pencil, not in stone
Again, we can't emphasize enough that roadmaps, or the Scrum artifacts in general for that matter, are not a promise. They are a forecast, that we can adapt based on new insights. Keep updating them as you progress, and use them as input for decision-making. But keep thinking and talking, don't blindly follow whatever is planned for at the beginning of the endeavor. We're curious about your experience with Roadmaps. What kinds did you use? How did it benefit your team? Feel free to let us know in the comments!