The map of the  Inca Trail is its own story map.

This map of the Inca Trail is its own story map.

Product backlogs are lists of “work to be done” at different levels of granularity and priority.  They can be large and unwieldy. It is hard to see the big picture of the work, regardless of whether they are in analog form (e.g. sticky notes or 3×5 index cards) or are housed in a tool (e.g. Version One or LeanKit Kanban).  Story Mapping is a technique that teams can use to help visualize a product backlog. Importantly, it lets the stakeholders understand the big picture, prioritize work and plan releases.

The Story Map describes the big picture so that all the stakeholders can visualize the scope of the project. Jeff Patton, the creator of the Story Map technique said, “One of the most common complaints I hear from Agile teams is that they lose the big picture.”

The Story Map shows the context of what is being built and how it relates in the big picture. They arrange Epics, which are large stories, horizontally in a chronological or functional flow (left to right), then under each epic, there is a breakdown of the stories or tasks required. Visually you can look at any large story and see what is required or if you have missed something.

Simple Story Map

Example: Simple Story Map

Once the stakeholders understand the big picture the Story Map can be used to prioritize stories and to define a minimum viable product. Let’s say you were developing an application to house customer names and addresses.  One of the larger stories might be “a customer service agent needs to be able to maintain customer names and addresses.” The breakdown of smaller stories might be:

  • Display customer name and address
  • Add customer name and address
  • Change customer name and address
  • Delete customer name and address

The Map also helps expose the relationship between stories.  For example, you will need to be able to add a customer before you display a customer and you have to be able to display a customer before you can change a customer.  The Map helps identify those types of relationships.

The Product Owner and/or other stakeholders can assign priorities to the list, using a simple forced ranking techniques or more complex techniques in which they assign business value, and indicate whether specific pieces of functionality are required to support a specific release. The prioritized Story Map makes identifying the minimum viable product much easier. For example, let’s say the delete functionality was not prioritized very highly. With both the big picture of the functionality and an indication of priority, the team can have an informed discussion about whether the delete function is required in the initial release (i.e. is it part of the minimum viable product?).

Combining the Story Map, the minimum viable product and the team’s velocity provides a perfect platform for release planning and visualizing release plans. Groups of functionality can be gathered together based on the team’s velocity, which is a proxy for team’s capacity to identify sprints and releases. In practice, sprints and releases can be denoted using many techniques, from hand written notes on story card, colored flags or colored sticky notes. Given that the release plan is dynamic use a mechanism that causes you the least amount of rework.  For instance writing the release on the story card in indelible marker will generally cause you to rewrite cards as things change. The more visual you make the release plan, the easier it will be for everyone on the team to understand the ultimate goal and the path the project intends to use to get there.

Story Maps are a technique to help teams develop a big picture of their project, so they understand where they are heading.  The Story Map technique can be used as a tool to organize your backlog and then maintained to show progress.  Using the power of the visual organization, Story Maps, and the inferred relationships that the map helps expose, provide more information for stakeholders as they determine priority. Priority and the functional maps also provide a springboard to discuss what the minimum viable product will be and the release plan for the project.