We know that a prioritized backlog helps us understand what to do next, but sometimes it's difficult to grasp where we are and where we should go -- especially if we just dive into a big project that's been started, with hundreds of stories and/or issues already created.
To solve these situations, I have found it very useful to manage the road map 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 (from Jeff Patton's The New User Story Backlog Is a Map).
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; vertically, 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 restrictions as to what I have in the grid. Here we can find stories with estimation, without, simple ideas not even confirmed, or 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 divisory 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.
Given my experiences, I always try to have the next three sprints already prioritized (at a high level), but of course they can change radically if the necessity appears.
The story map is not static, but very much alive! I have found myself updating, prioritizing, adding, and removing stories every week.
For obvious business reasons, I have removed the content from it, but here you can see the same Agile road map in two different stages of the development:
First contact
After a couple of sprints
What are the differences between blue and red boxes? Colors can be used in different ways. 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 colors for many different purposes. For example, use different colors:
-
Depending on the estimation (or if they are not estimated yet)
-
To identify complexity
-
To split between technical and business
-
Even to 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 an approach for the following ones.
There is a phrase in Mike Cohn's Agile Estimating and Planning that has had 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 "must" for any of my future projects. The stakeholders can easily grasp the velocity of the team and the status of the product, and they can help by introducing 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" (noted above). This is just my experience with it, how I have used it, and what I have changed from the original idea.
Are you using a similar tool?
What is your experience?
Do you have any suggestions?