In most companies you find Product Backlogs prioritized by business value, as Scrum told us to do for several years. Since July 2011 the Scrum Guide softened this requirement, speaking of backlogs “often ordered by value, risk, priority, and necessity”. Either way you face the problem to have to split complex funtionalities into smaller ones and put them in a one-dimensional list. User Stories belonging to a certain Epic are usually not organized as a block but are interrupted by other Stories belonging to other Epics. Did you ever try to give your stakeholders the big picture just with your product backlog at hand? Or even just gave them the Product Backlog to read? No way. Some time ago Jeff Patton took care of this problem and came up with the idea of Story Maps. They offer the chance to show the whole product in a comprehensive way and make it much more easily explainable and discussable. With this article I would like to introduce the concept of Story Maps to you.

You need 

• a large area you can work at (a wall or the floor)
• Post-its like you use them for your User Stories anyway

First step

Think about the Epics describing your product and write them on the Post-Its. Afterwards put them on the wall, building a line from left to right. Epics on the left side are the ones to be implemented first. If you struggle finding an order think about the workflow the user will follow.

Second step

Go ahead and split your Epics into User Stories. Put the Stories on separate cards, using a different color. Don’t think about releases at this time, just write down your current vision of the final product with all comfort features you might want to implement over time. The result should look like the picture on the right side.

Jeff Patton compares this picture with a backbone and protruding ribs, that’s why the Epic line is often called “product backbone”.

Third step

With all your User Stories in place you should now prioritize the Stories per Epic. Order them by the MuSCoW principle (Must haves, Should haves, Could haves, Won’t haves) with the most important ones on top. Consider using a different card color for the Must haves, since these are the ones describing the so called “Walking Skeleton”. The term was initially used by Alistair Cockburn, who defines it like this:

“A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.”

With this two-dimensional Story Map you got an overview of your whole product. It is a perfect base for discussions with stakeholders in terms of business needs as well as with the team in terms of dependencies. At a glance you can take in the whole product and you know immediately what comes first.

As every good Product Backlog you should make the Story Map visible to everyone who’s interested. With the map visible you’ll get lots of feedback and valuable discussions will take place in front of the wall. 

To avoid losing the big picture User Stories that made it into a Sprint should not be removed from the map but duplicated. Mark them on the Story Map as part of a certain Sprint and cross them out as soon as they’re done.

1,5 years ago I used to work with a group of product owner and interestingly enough we came up with something quite similar to the Story Maps described in this article. Neither of us knew about Story Maps back then, we were just following our instincts. The product was quite complex and we got good feedback from the team as well as from the stakeholders who appreciated such an overview.

What are your experiences trying to describe your product to other people? Do you already use Story Maps? Do you know other techniques? Just let me know in the comments.