Product Roadmaps
Hey everyone,
I know product roadmaps are not something recognised within the Scrum guide, but it's something that those in a product owner capacity will encounter from time to time (if not all the time!), so I'm interested to understand different opinions on them.
Trying to be impartial:
Pros:
- They provide a useful reference point to communicate product vision, so help with transparency.
- They're accessible at all times to all people, whereas a product owner cannot always make themselves available to everyone, everywhere, which may help with inspection - knowing the longer term path may trigger conversation / adaptation earlier on.
Cons:
- Are they not simply a replication of the product backlog, only displayed linearly?
- They become obsolete after sprint review, if the backlog is adapted to respond to new information
- No date added to a roadmap is valid, due to the changing nature of development, and because our only timebox is the sprint; and with no dates, it's simply the backlog on the side again
Personally, I just can't get on with roadmaps:
- They feel unnecessary - my product backlog is my roadmap - those items at the bottom of my backlog are where we'll get to
- They feel like waterfall timelines!
- They feel restrictive - outlining a roadmap feels as though it comes with the expectation of "locking in"; which is entirely impractical in Scrum - we inspect and adapt the backlog regularly based on feedback
- They're either too vague to be meaningful, or too much of a commitment to be achievable; both scenarios only leading to a lack of transparency (IMO), whereas the roadmap is transparent - the detailed items at the top are coming soon, the less detailed items at the bottom will come later, but all of that can change after each sprint.
So I guess to get to the nub of the issue - do roadmaps have real place in Scrum? Or are they merely a symptom of a product owner failing to deliver a clear vision and/or express the importance of the product backlog? Or is the product backlog just not visible enough for inspection?
Looking forward to your thoughts, and thanks for reading.
I used roadmaps in some projects to order my product goals and have only PBI in the product backlog for the current product goal. and use the roadmap to discuss the value of the current and future product goals with stakeholders.
Where for some stakeholders the product backlog has to many details to see the overall picture of in what order they can expect what value
As per The Professional Product Owner book, Scrum is augmented by many practices. Product management being the outer layer which is where roadmapping resides.
A story map could be thought of as a different kind of roadmap where the first release is your Minimal Viable Product (MVP).
Impact mapping allows for more effective roadmapping.
On top of this, working in Sprints with “Done” Increments at the end of each Sprint facilitates ongoing learning about what the Scrum Team builds and how they work together. This covers customer feedback, scope, tests, integration, and many more elements. This feedback allows for validated learning. Those learnings in turn drive the scope and roadmap.
Also, as all decisions are being validated, this process leads to better choices regarding the roadmap and the scope within, which in turn causes less scope creep and waste along the way.
do roadmaps have real place in Scrum? Or are they merely a symptom of a product owner failing to deliver a clear vision and/or express the importance of the product backlog?
A Product Backlog should contain all the information needed to support forecasting, planning, and reporting.
If a separate roadmap is thought to be necessary, you have transparency over a deeper problem. It could be something along the lines you suggest, or it might be more fundamental than that. For example, there could be a failure to embrace product emergence by demanding a more prescriptive artifact.
Product roadmaps exist to help the customer see what they'll get for their money and when. It also helps the product team visualize what they're building toward. Some level is planning is necessary because no VC is just going to fund a product manager and not expect a blueprint of some kind.
I agree with @Mark Adams. A combination of Product Roadmap, Product Goals and the important milestones along the way serves its own important purpose (although not from a Scrum team's perspective essentially) and cannot be discounted.
Its plays a particularly crucial role when we go to the Clients for new business/ additional funding or contract renewals. They are more interested in seeing the 'bigger picture' as when are they going to get their products out of the shelf and into the market (as they need to then pass along the same info to their end-users). They're generally quite impatient to hearing about any details, including the current shape of our Product Backlog. You show them a nice roadmap with goals-labelling and important milestones marked along the way (all dated) and they're happy. However, we should always maintain a constant line of communication open to them to keep them informed about the shape our product is taking place (transparency) on the latest knowledge learnt (inspection) and the necessary course corrections needed (adaptation).
Having said that, it doesn't necessarily fall under the purview of Scrum. Its related to Product Management and Stakeholder Management. To the Scrum team, they should still keep themselves focused to the overall Product Goal and to their Product Backlog and Sprint Goals as part of their ongoing work.
Very interesting feedback & opinions on this one, so thank you for taking the time to reply.
Just to pick up on something that Mark raised:
Some level is planning is necessary because no VC is just going to fund a product manager and not expect a blueprint of some kind.
As a product owner, shouldn't I be empowered by the VC to make the right calls and deliver on their vision? If I'm hitting or exceeding my value metrics with each increment, why would the VC need any more? && Isn't by backlog my plan?
I wonder if there's a lack of empowerment for Product Owners to do the right thing with decision making and autonomy, leading to supporting artefacts like roadmaps.
I do like Sven's usage of a product roadmap being a more digestible snapshot of the backlog, but perhaps this is simply a view of the epics in the backlog as opposed to the full backlog....