Product Backlog vs Story Maps

Email Notifications

SHARE
Request to reuse this

A product backlog is the entire list of all the "features, functions, requirements, enhancement and fixes" identified as being needed to produce a product or solution. Typically, these features are broken down into user stories, and these stories are generally understood to constitute the majority of the Product Backlog. However, not all of these items will actually end up in the product/solution, due to prioritization and certain constraints (ie. time and cost).

The Scrum Team occasionally works together to refine user stories, and work on prioritization. This is crucial in order to know what is valuable to the customer, and what trade-offs we can make if a particular constraint forces us to pick and choose between what stories are in and what stories are out.

But what if the backlog is large? When we sit down with the team and especially the customer, should we hand out a long list of potentially hundreds of stories, and be flipping between them? Can we really get an idea of the entire product or solution that way?

In 2005, an Agile practitioner named Jeff Patton had similar issues with the Product Backlog before eventually describing it as a "bag of context-free mulch". He decided to come up with a smarter solution; something that was in his view a "better version of a product backlog". And so, the Story Map was conceived.

Basically, to create a Story Map, we take sets of features and their associated stories, write them onto sticky notes, and lay them out horizontally, while grouping the stories by feature vertically (in ascending order of value/priority). What we get is something like this:
 


Imagine each of these sticky notes describes a feature or user story. Can you see that this visualization is a little easier to look at than a long list of the same descriptive items but in text format?

Ok now that we have a basic Story Map, how do we structure it? Well, the top line (blue) is what we call the Backbone. These are the features that are critical for the product to function and are non-negotiable. The second layer (pink) includes the minimum set of features and stories that the customer defines as the Minimal Viable Product or MVP; sometimes called the Walking Skeleton. The Scrum Team knows that they must deliver both the backbone and walking skeleton in order to have a viable product as determined by the customer.

Underneath the backbone and walking skeleton (yellow), we have the remaining user stories, with higher priority ones toward the top, and lower priority ones toward the bottom. Our Story Map now looks like this:



Obviously the Story Map is often a lot bigger than the one we have shown here. It could fit onto a large whiteboard, a section of the wall, and I have even seen them extending down a hallway of an office building.

Now, we can go another step further with the Story Map. Once we are pretty confident of the features, stories and the map, we can then start planning our releases, to which our Sprints will eventually be scheduled within. Once we get down to this level of planning, our Story Map becomes a Product Roadmap, which is basically a Story Map with a simple project timeline.



Which would you rather work with when discussing the project with the team and customer? A traditional product backlog, or a Story Map and the subsequent Product Roadmap? Remember, we always need the Product Backlog as this is the master file of all the items that will and could be in the final product. A Story Map and even a Product Roadmap (with only upfront releases) may not show all the stories.

So in summary, what are some of the advantages of using a Story Map over a product Backlog?

1. Easier to breakdown the product into releases, and MVP
2. Better visualization of the Product Backlog
3. Easier to show customers and stakeholders key areas of the product
4. Easier to enter the Story Map data into software such as Jira
5. Relative sizing is easier when you can see the stories laid out
6. Makes Prioritization less complicated

Can you think of any others?
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!