Creating an Agile Roadmap using Story mapping
We know that a prioritized backlog helps us understand what to do next but sometimes is difficult to grasp where we are and what we should do next, especially if we just dive in a big project already started with hundreds of stories and/or issues created.
To solve these situations, I have found very useful in managing the roadmap and backlog with the help of a story map.
A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that deliver value to users and business with each release. [original article]
Where to start?
First, we group the stories by application/theme/functionality and create the grid.
Horizontally we can find the title for each grouped functionality.
In each column the main stories/issues related to each group.
The functionalities are prioritized from left (more important) to right (less important). Each group will then have the stories prioritized again vertically.
Personally, I don’t have any restriction to what I have in the grid, here we can find stories with or without estimation, simple ideas not even confirmed and including needed technical improvements.
Anything that helps understand the status of the project is welcome to be here.
Grouping and prioritizing
Once the stories are organized, we can start the surgical operation: slicing the list!
Creating the division line is not more difficult than the typical task of prioritizing a backlog, but personally, I find the map even easier than managing a list of stories.
In my experience, I always try to have the next 3 sprints already prioritized (high level), but of course, they can change radically if the necessity arises.
The story map is not static, but pretty much alive!
I have found myself updating, prioritizing, adding, removing stories every week.
For clear business reasons, I have removed the content from it, but here you can see the same agile roadmap in 2 different stages of the development:
First contact
After a couple of sprints
What are the differences between blue and red boxes?
Colours can be used in different methods, for example in this case I have used them to identify the main objectives of each sprint.
But there is no straight rule, we can use colours for different purposes, for example:
- Use different colours depending on the estimation (or if they are not estimated yet)
- Identify the complexity
- Split between Technical and Business requirements
- Or even identify new functionality added in a second instance
I have personally found this tool really interesting and easy to manage.
It allows both team and stakeholders to understand:
- what we have done
- what we are doing
- what we are going to do
As a team, we are able to show the work we have accomplished in each Sprint and establish a priority for the following ones.
There is a phrase in “Agile Estimating and Planning” (by Mike Cohn) that have a great value for me:
Agile planning balances the effort and investment in planning with the knowledge that we will revise the plan through the course of the project.
In my experience so far, I believe this tool is reliable and I am sure it is going to be a valuable step for any of my future projects.
The stakeholders can easily grasp the velocity of the team, the status of the product and help to introduce or suggesting new changes.
Clearly, the idea and the process is not new, I base my work on the concept of Jeff Patton explained in the article The New User Story Backlog is a Map.
This is just my experience with it, how I have used it and what I have changed from the original idea.
P.S.: I originally wrote and published this article in 2013 for Scrum Alliance, but because it was removed (do not know why yet) I decided to re-publish it here as it was originally written.
P.P.S.: The images added here are my own and are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
