Project Management

Product Backlog vs Story Maps

From the Scrumptious Blog
by
Scrum is the most popular framework used within an agile environment to convert complex problems into valuable products and services. In this blog, we will examine all things Scrum to shed light on this wonderful organizational tool that is sweeping the globe. There will be engaging articles, interviews with experts and Q&A's. Are you ready to take the red pill? Then please join me on a fascinating journey down the rabbit hole, and into the world of Scrum.

About this Blog

RSS

Recent Posts

The Agile Engine

Scrum at School

Why SAFe may not be safe

Scrum on Mars

Scrum vs Kanban



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!
Sante Vergini Signature

Posted on: April 26, 2018 08:37 AM | Permalink

Comments (17)

Please login or join to subscribe to this item
Thanks for breaking this down in such simple but educative manner!! Managing scrum projects will be easier considering the many advantages of Story Map over Product Backlog

Very interesting and useful information abut managing backlog!! Thank you Sante for sharing. Good Day.

Thanks for sharing the value of story mapping with the community. User Story Mapping is a great book on product development regardless of the approach utilized.

One additional benefit of story mapping is that it takes the negotiation process around scope & schedule/cost to being more of a collaborative process involving all key stakeholders. This is especially true when a physical story map (old school with Post-it notes) is used...

Kiron

Thanks for sharing the importance of story mapping over a product backlog, Sante.

This is very interesting and I would like to hear more about it.

Thanks Cibin, Sandeep, Eduin, Kiron, Anish and Andrew.

Cibin, the community consists of experts and novices alike, so I try to write each article with that in mind.

Kiron thanks for that addition. The birds-eye view nature of story mapping indeed assists the collaborative process between stakeholders. The old-school way still beats out high-tech tools such as Jira in many respects.

Andrew, this blog from time to time will share all kinds of information and insights into the world of Scrum.

The only limitation to visual story maps is that it is difficult to depict in virtual team scenarios. We can only see so much of it on our tiny laptop screens.

A way around for that would be to use a spreadsheet solution to map out the coloured 'stickies'. At normal zoom, the text is legible -- and at minimum zoom, the entire patchwork of the story maps is visible.

Users can control the zoom to get to what they want.

Very true Karan, there are limitations with almost any system. The software options like Jira help a little bit, but like with your example of spreadsheets, they are limited by screen size.

Story Mapping is a very beneficial like you mentioned Sante and it can apply to any industry. It is a good way to plan, and also good way to assess your risk while prioritizing.

Agreed Rami, there are many applications for story mapping outside the software industry.

Story Mapping is a very beneficial and I think it is the backbone of the whole thing.

Very interesting and nice approach, especially how you link the product backlog to the product roadmap via a story map. The concept of the "backbone" and "walking skeleton" I feel is the "golden nugget" because they clearly indicate the bare minimum of what must be delivered in order to be viable product, i.e. for the product to "stand and walk" (some more imagery) :-)) This will help manage the risks around product release. Thanks Sante for sharing!

Thanks Amitabh, Agile and Scrum are filled with golden nuggets.

Structured and elaborative article on backlog and study maps. Thanks Sante! New to Agile and founding your blogs quite helpful.

Thank you Apporva. Happy you liked it.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"The illegal we do immediately. The unconstitutional takes a little longer."

- Henry Kissinger

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events