Skip to content

Story Mapping

Story Maps are a different way to visualize your Product Backlog. This post will give you a brief intro so you can build your own.

What’s the Problem

We all know that the Product Backlog is the prioritised list of user stories we need to implement in up coming releases. So what are the problems that exist with a backlog that might cause us to look at another tool to use in conjunction with the backlog.

  1. Backlogs are usually lists in Excel and make it difficult to visualise what needs to be done.
  2. There is no way to show a connection between a larger feature and the 3 smaller stories that make up that feature in a backlog.
  3. The order of workflow is not visible in stories in a backlog.
  4. Usually release scoping happens at the larger feature level since it’s unwieldy to work at the lower story level when planning releases.
  5. Backlog’s don’t offer any way to confirm if you’ve covered everything.

What is a Story Map

User Story Maps are a way to organize user stories that help visualise your backlog. Generally they are created with sticky notes on a wall (but you know someone has probably written a tool to do this as well) They don’t replace a backlog, but are great to use in conjunction with a backlog, or to help create an initial backlog when you are starting a new project.

The idea is to think about what users want the product to do and group into 3 different levels. User Activity (highest level), User Task (middle level) and Sub-Task (lowest level). For each user activity there can be multiple tasks and for each task there can be multiple sub-tasks. Usually the sub-tasks end up being the stories on the backlog, but this way they are related to the overall task or activity the user is trying to perform which provides context.

The actitivies are laid out so that time flows from left to right. For example: Create new customer would be on the left hand side and archive old data probably on the right. Sub tasks can also be laid out so that higher priority/more necessary ones are higher up and nice to haves are lower down.

Once the activities are laid out, you can decide on which are required for each release and draw lines across the map to indicate this.

How do Story Maps Help

Story Maps have been popularised by Jeff Patton as a solution to some of the problems above. Here is how they help:

  1. They help group related stories together and provide context of what the user is trying to achieve.
  2. They help facilitate story breakdown from a user point of view rather than a technical point of view.
  3. They help stakeholders scope releases at a more fine grained detail by selecting the walking skeleton, rather than all the bells and whistles, and this usually helps the team deliver a first release much sooner.
  4. They help create and visualise a goal for a particular release.
  5. They help teams see where they are in terms of delivering functionality for a release.
  6. They help drive out requirements that were previously missed.

How do I Create a Story Map

  • Build the map
  1. Decide on user roles – come up with some user roles who will interact with your Product and define these roles.
  2. Brainstorm the types of things each of these users would want to do with the application. Decide which of the 3 levels each item is: User Activity (highest level), User Task and Sub-Task (lowest level). Use a different coloured post-it for each level. Focus on breadth vs depth first.
  3. Arrange the activities so that the workflow moves from left to right in terms of time when the user would perform that function.
  • Validate the map
  1. Once you’ve got a basic map you can socialise the model with other stakeholders to ensure nothing has been omitted.
  2. On review you might add stories, combine stories, reorganise etc.
  • Plan the releases
  1. Once you have a map most people are happy with, you can then identify the goals of the first release.
  2. Based on these goals you can arrange the sub-tasks in priority order where higher up is a higher priority.
  3. You can decide which items are necessary for a first release and which can wait for a later release.
  4. When you’ve agreed the first release you can draw a line under all the sub tasks which make up the first release.
  5. You can keep doing this for subsequent releases.

For more info check out the following links:

A similar idea which has been around quite a bit longer from the XP world is Dimensional Planning


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: