An introduction to user story mapping

user story mapping

In a previous post, looking at how to take a digital product or service from an idea to an actual plan for delivery, I stressed the importance of setting a vision, a shared understanding among the team of what’s being built. But once you have a vision, how do you then translate it into a collection of user stories to populate a product backlog? How do you put those user stories in order of priority? And how do you make sure you haven’t left out some important piece of functionality?

Keeping the focus on value

To generate a product vision we started by listing the different users and their needs, the features that would help meet those needs and the value that would be generated. So we already have some features listed that can form the basis of our product backlog. But it would be a mistake to start trying to build out our backlog from these features alone, stripped of their context and detached from the value they’re supposed to deliver to the user and the business.

Rather, we should treat the product vision board as the first iteration of something which needs fleshing out in all its dimensions – not just in the ‘features’ dimension. Further work and conversations are required among developers, product managers/owners, business analysts and UX designers about who our users are, and how best to meet their needs in way that’s feasible and which creates value for the organisation.

We made a lot of assumptions when we made our product vision, assumptions which now need to be validated or dropped as they come into contact with extensive user research (both qualitative and quantitative), personas and conversations with business stakeholders. We need a good technique for capturing the team’s understanding of the product through all these developments.

Introducing story mapping

Story mapping is a technique championed by Jeff Patton. It provides us with a way to envisage the entire product or service as a series of tasks which the user completes.

In purely practical terms, it involves building a grid of user stories which are laid out under headings that represent the user’s experience moving through your product. This can be done iteratively over a series of conversations between team members. So a first attempt might look something like this, with user stories grouped under their respective features (some might call these top-level features ‘Epics’).

user story mapping

Here we have the high-level features of our product (the backbone, if you like) broken down into component user stories. It’s easy to see which feature each user story belongs to and so each user story is presented in the context of the whole product, not just as an item in a list.

Whilst this approach is helpful for organising our thoughts – it’s already much more informative than a simple list of stories – it doesn’t really yet constitute a story map, since it doesn’t take into account the flow of the user’s journey.

Developing the story map

Let’s make our example more concrete by imagining a simple ecommerce website, where the product vision board makes reference to three features:

  • Product page
  • Product search
  • Checkout

The initial story map might look like this:

a simple user story map

We have the ‘Product page’ feature with the user stories related to that feature listed underneath, and ditto for the ‘Product search’ and ‘Checkout’ features. But these stories aren’t particularly well developed yet, and there’s no indication of how important each is.

For example, a user needs to read a product description before ordering but does that happen before or after they’ve read the reviews? And which offers more value to the user?

After more research is conducted, and more input from stakeholders gathered, another iteration might look like this.

a user story map which takes account of the user journey

Notice that we’ve refined our user stories by breaking some of them down into smaller pieces, we’ve introduced a new dimension whereby stories are arranged in order of where they come in the user journey, and we’ve started to arrange the highest priority stories near the top of our map

Developing further in this direction, it’s easy to see how, eventually, we might arrive at a map that indicates what stories need to be included in the first few releases.

a user story map which indicates releases

Story mapping as an iterative process

All this detail will have come from a conversation between team members and stakeholders about how best to deliver the most possible value for the user and the business as early as possible. The story map provides a framework for that conversation, a way to visually represent ideas during the conversation, and a way to record the outcomes that, unlike a flat product backlog, captures all the context of the user’s journey.

The story map, like the product itself, is always a work in progress. It gives us a snapshot of the team’s thinking at the time. As we continue our discussions with users and stakeholders, as further evidence is gathered which validates or invalidates our assumptions, the story map can change and develop accordingly.

By grouping user stories by feature, the story map makes sure that we create meaningful releases which allow users to complete end-to-end journeys. It helps us build a first release that’s a minimum viable product and then iterate on it, bringing new value to the business and the user with each new release.


Leave a reply

You can use these tags:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  1. Juan says:

    Nice post. I like user story mapping, but I have a doubt:

    How many user story maps are there for a product? Just one? Or one map for each journey of the user?

    I had understood that there are just one map for the whole product, but if the product isn’t a very basic one with just one journey, how do you put all the journeys in just one map?

    Thank you.

    • Eldlabs says:

      I usually have one map for each product. It makes thing easier. It also helps you to visualize what is the cost of implementation for every project, so you can plan between products.

  2. […] use StoriesOnboard  – and online tool for user story mapping, which I use for big picture business /strategic planning and Trello for more operational […]

  3. James Sear says:

    Nice! I actually like naming the steps through the journey (or epic) too, so you get a three tiered view of the journey.

    @Juan. One map per product, definitely. The fact that it’s all in one place is actually one of the major advantages of story mapping. You can draw relationships between different user journeys.

    Post-its are an excellent place to start, but if anyone is interesting in going digital, please checkout our product: https://www.avion.io

  4. Adrian says:

    Thank you for this. It helped our team a lot!

    All the best!

  5. […] Here’s what it looks like (it was created by taking inspiration from Jeff Patton’s User Story mapping): […]

  6. RoyK says:

    Really clear explanation of the concept, thank you for this.

  7. Rish says:

    Well explained, thanks for this. How’s the user story mapping related or linked to Product Roadmap? Is that story mapping provides an input for Product roadmap?


    • Gemma Reeve says:

      Hi Rish, thank you for getting in touch. In answer to your question, they’re not really related, they are separate things –
      User story mapping: maps a journey that a user will take and therefore shows what the priorities are to be designed & developed.
      Product roadmap: timeline of products to be developed

  8. […] Storymap – An introduction to user story mapping by Jim Bowes […]

  9. Thank you very much for this insightful video.
    We’ve developed Draft.io as a visual and highly flexible support, inherently collaborative. Let’s have a look at the following example if you consider performing the Story Mapping exercise in digital: https://draft.io/example/story-mapping

    Hope it will be useful for some of you! We would be really grateful to get your feedback in order to improve it for your usage.

  10. Lech says:

    Great post and a thorough explanation of Story Mapping technique! If you would like to start doing story maps, here is an article that describes a workshop and some tools that will help you to begin with: https://medium.com/scrumtale/improve-your-product-backlog-with-story-mapping-and-scrumtale-d0f1fca5ecd3?source=friends_link&sk=5a96e371fe6e33e6e81029e6f312a702

  11. Sreenivas says:

    Thank you for making to understand the story mapping process easily. In our environment, we create EPIC,SUB-EPIC,FEATURE and User Stories.

    All these 4 are used to map to user needs or how they use the system.

    Releases are planned based on the features level.

    Are we complicating the process by having 4 levels of divisions on capturing the essential work to be done?

    • Gemma Reeve says:

      As a rule of thumb keeping things simple and smaller is easier for the team to deliver, and also for the product owner to prioritise when needing to look at the big picture.
      However, if the team / organisation isn’t struggling to deliver with your current structure then there’s probably no need to change it. The main thing is to be adaptable to your environment.

  12. […] An introduction to User Story Mapping, Manifesto […]

Sign up for the Manifesto newsletter and exclusive event invites