A roadmap. Why in Agile?
In Agile it all begins with the idea detailed in the product backlog with help of epics, features and user stories. This feature breakdown view is great for the shaping of the product, but it is not very practical for preplanning & planning activities. Especially long-term and mid-term.
Of course, there is a possibility to plan a release and multiple sprints ahead, but, as a product owner, you do not want to plan user stories too far ahead. You even do not have them as (if you do Scrum correctly) you apply As Late As Possible principle. Add details once they are necessary.
Even in Agile, the product manager and very often product owner is responsible for go-to-market strategy. Very often such a strategy is represented by the product roadmap.
The roadmap is the tool to plan product go-to-market strategy
The roadmap also should help with the tracking of plans versus reality. As the product owner, I want to:
- Identify slacks in plans pretty early,
- Run what-if analysis on how additional changes impact my roadmap and plans.
- Sometimes product owner needs to support work queues for multiple teams and level the product development based on the velocity.
- I need to manage project milestones declared by our clients and see them in the context of releases and sprints.
What can be found on the roadmap?
The product roadmap shows:
- a lane (Slovakia, the United States on the picture above) to track country, portfolio, project, etc.,
- a group (teams on the picture above) that breaks lane into smaller areas (team, product in the portfolio, project, location, technology, partner, etc.),
- a row in which features are located. There might be multiple rows as boxes do not overlap in case they start at the same time interval,
- colored boxes represent epics and features which can be scheduled on the timeline,
- ghost boxes – reality vs. plans,
- orange flag – releases,
- green flags – sprints,
- the red flag – the current day and
- blue flags – milestones.