How to do user story mapping (and why you should)

What is user story mapping?

User story mapping is about having conversations—telling stories—about users and products to build shared understanding between those involved in creating a product.

Shared understanding helps teams build the right thing for the right people for the right reasons.

Okay, it’s a bit more complex than that, but that is what you do.

You start big, go deep, and then slice back to what can be reasonably delivered to give the best outcomes for your business, customers, and users.

User story mapping gets you to consider a product and its software by thinking about:

• Users and their context;
• The activities these users are trying to carry out;
• The steps involved in that activity;
• The details of the steps involved in those activities;
• How this all links to desired user and business outcomes.

The story map can help you see how the user currently interacts with your product so that you can then talk about the future. A user story map can help you find out what could deliver the right outcomes—see the gaps where you can do something.

But, and it’s a big but, there is one crucial thing you need to keep in mind if you do decide to do story mapping:

Understand that you can’t build everything (you’ll see why later).

With the above in mind, here’s why user story mapping is fantastic.

Why you should do user story mapping

Remember that video at the start of the post? No one understood what the other was doing or needed.

User story mapping builds shared understanding, enabling people to “externalize” their ideas and knowledge with more than just words written in a document. (Or diagrams drawn on each other’s backs.)

As Jeff Patton points out:

“Shared understanding is when we both understand what the other person is imagining and why.”

Source: User Story Mapping, p. xxxii

You can sketch, playact, point, show videos, and make connections when you talk to people. User story mapping helps you all convey understanding in ways that pushing over a big ol’ requirements and plans file won’t do.

And by having these kinds of conversations as early as possible? It helps everyone realise quicker if they’re not on the same page and don’t understand this project’s needs.

Other benefits from a user story mapping process

Aside from building shared understanding, there are a bunch of other benefits created by the process:

• Story mapping can help you reduce waste over the course of development by encouraging a cycle of planning, building, and learning.
• Story mapping ensures sprints are coherent and so that they make sense in their own right—delivering something that’s meaningful to the user. (Meaning any sprint is a release candidate.)
• When you’re not sure what needs to be a priority, the mapping process can help you slice through what you’ve uncovered to see what you should prioritise and in which order.
• User story mapping helps you build those links between user needs, business needs, and what your software teams and product teams can do to meet those.
• Mapping can help your team and external teams to increase the accuracy of time and cost estimates. How? By basing it on far more concrete information revealed during the mapping process.
• Running through a workshop can help you see where everyone needs to do more learning before building something for release.
• User story mapping can help you identify knowledge gaps or uncertainty, and risk.

Story mapping is certainly an enabler for Agile and Lean-Agile evolutionary lifecycles where teams are always delivering outcomes that serve users and the business.

Here’s how you can start to do some user story mapping of your own to help you build a backlog with clear priorities.

How to prepare for a user story mapping workshop

Before you jump right into the process, there is some prep work to ensure you get the most out of the workshop.

1. First up, you’ll need someone to run the workshop

If you’re not going to be the one running the workshop, then look for someone who has that cross-org sight on product development, business needs, customers, and so on. Someone like a product owner or product manager would have that broad level of insight and stellar facilitation skills.

2. Pick out your story mapping team, and limit it to ten people or fewer

The people who attend should come from the different teams/departments responsible for product success. You’re keeping the number to ten or fewer so that everyone has the chance to be heard during mapping.

These people will also have different perspectives relevant to having an in-depth mapping workshop. Consider inviting people from positions like:

• Key stakeholders (such as business owners and/or investors, or product owner);
• User experience (UX) designer or researcher;
• Hardware engineer (if it’s a product with an embedded system);
• Software engineer;
• Marketer;
• Someone customer facing, such as a salesperson and/or technical support;
• Project manager;
• Someone who understands the technical domain, such as a subject matter expert;
• Compliance and/or quality expert (if your product is in a regulated space).

The people you pick from the above roles should be decision makers in their respective teams/departments.

Having a mix of people during story mapping is great because you have key decision makers in a room together with people involved in delivering the project. Hearing first hand what’s needed is great for the development team. People can ask and answer questions in a way that plans, and requirements just doesn’t enable.

3. Round up existing documents before the workshop

Okay, yes, if you already have documentation because it’s an existing product or you’ve already started planning it, you might want to bring those docs to the workshop. Some of the people you’re inviting to this workshop might be able to help you with this.

The kind of documents you’ll want to consider obtaining include:

• User personas from your UX experts;
• Customer feedback from sales and marketing;
• Relevant technical documentation;
• Any compliance standards docs if your product is for healthcare, aerospace, and so on;
• Current estimates.

Don’t worry if you don’t have all of these because the business is new or it’s a greenfield project, or you’re looking to launch into a sector/market you’ve not sold to before.

It’s worth noting that if you don’t have user personas yet, that will be a risk (more on that further down).

Collate this information so that it can be accessed during story mapping as needed.

4. In-person or online workshop?

You can do story mapping online or offline. But you need to ensure you have the tools for running it.

In-person

If you’re doing user story mapping in-person, it’s helpful to have:

• A room with plenty of clear wall space (empty whiteboards can be handy) or floor space (or both), and (if possible) make sure it’s a place you can leave the map up to keep so that people can refer to it often;
• Super sticky Post-it Notes in a variety of colours (you’ll thank me later when they don’t fall off things easily);
• Index cards;
• Blu Tack or similar;
• A lot of pens (permanent markers for the Post-Its and Index cards, dry wipe markers for whiteboards);
• Paper for sketching out more extensive ideas and details;
• A phone with a camera or stills camera (to take photos as discussions progress and in case the super sticky Post-its and Blu Tack fail, and to share the maps with teams later);
• Optional but helpful: someone to film the workshop to capture the conversations that happen.

Online

Whether everyone must work from home or if your team has always been remote only, it is possible to run user story mapping entirely online. It’s handy to pick conferencing software that allows you to share screens and record call audio and video.

You’ll want to use a user story mapping tool that can help you map. It could be freestyle (and will be more like an in-person mapping experience) such as Miro or Mural or you could use something more structured like Jira.

(Here at Bluefruit, during the pandemic, we’ve been using Miro, and we have a handy free user story mapping template on Miroverse that you use for your mapping session.)

5. Learn the structure of a story map

You can read user story maps to varying degrees of depth. But they look a lot like this:

Yours might end up with more depth or one that’s longer. It all depends on your project. It might cover all the walls in your workshop room.

In general, “The BIG story” of the map has a narrative that flows from left to right.

The cards should have “short verb phrases” that explain what the users in your map are doing or trying to do. Short verb phrases are things like log on, press the start button, or say “cancel” where a user is performing an action.

Jeff Patton points out that some people might find it hard to break the habit of writing about features first, but the aim here is to write about users and their actions and what they’re trying to do.

6. You’re ready

Pick a time and a place and get ready to have a detailed conversation to build shared understanding.

How to run a user story mapping workshop

It’s your workshop day. There are a few things your facilitator will want to do before you get right into writing down user stories.

Ask all participants to be an EETT

Set some ground rules for participation at the start of the workshop. Suppose your business doesn’t already have guidance on how to have inclusive discussions where everyone takes part. May I suggest asking your participants to each be an EETT?

Empowering: Ensure everyone has the chance to speak and finish speaking their thoughts, and remember there are no stupid questions—all questions are valid.

Empathetic: Think of the user and think of the people working on the product; think about their needs.

Trusting: Trust that the people here in this workshop know how to help this workshop and project succeed.

Transparent: Be clear, including expectations around how much time things will take, what the risks involved are, or if it’s something that there is not enough in-house knowledge or skill around.

Explain that there is always too much to build and that you can’t make everything

What will become clear when you run through the first three steps of story mapping is that it will always appear that there is too much to build. And it will feel like you must build everything before you start seeing results. As Jeff explains:

“Focusing on specific target outcomes is the secret to prioritizing development work.”

Source: User Story Mapping, p. 29

Help everyone understand that the process of mapping is about learning

As well as building shared understanding, mapping is about uncovering where learning is needed.

Mapping generates many assumptions, so afterwards, there will be more learning and discovery needed. You’ll aim to break that learning and discovery down into as smaller segments of learning as possible so that you can build and learn quickly. (Jeff borrows from Eric Ries’ book The Lean Startup when he discusses it, which talks about a cycle of “build-measure-learn”.)

Explain the steps of user story mapping

User story mapping generally has six steps as described by Jeff Patton:

1. “Frame the problem.” Discuss who your product is for and explain why you’re building it. Fill in those details on the context end of the board.
2. “Map the big picture.” Here the first real bit of mapping happens. Explain how you will all talk about the “big story” (that part in the earlier diagram) before going into any real depth. The big story is the summary goals that the user is trying to achieve.
3. “Explore.” Next, everyone goes “deep” and adds more depth to the map. Going deep could be around different users and how they do things, the tasks and sub tasks that lead to the completion of bigger goals. Here is also everyone’s opportunity to point out where the risks are from software to hardware, compliance, a lack of in-house knowledge or skill, or where user research is missing, to everything in-between.
4. “Slice out a release strategy.” As much as everyone can think of has been set down on the map. Now you’ll start to break the map up to uncover “minimum solutions” of what’s needed to make an impact with people and push your business towards its aims.
5. “Slice out a learning strategy.” Now that you’ve all got a “minimum viable solution”, Jeff reminds us that this is still based on assumptions. At this step, you’ll be slicing out “minimum viable product experiments” that a group of your users can try out, and you can learn what’s important to them.
6. “Slice out a development strategy.” Here’s where you slice your minimum viable solution just a bit more to uncover the parts you need to build earlier or later. Jeff recommends developing things early that can help you discover “technical issues and development risks”.

Source: User Story Mapping, p. 83

Start story mapping!

The facilitator should show people what the best practice for writing down goals and tasks looks like. So, pick up a Post-it and a pen (or your virtual card), and talk them through doing this as you place your first idea (which will likely be a step one card):

1. As soon as you’re thinking of an idea, you reach for a Post-it or index card to write it down.
2. You write a “short verb phrase” that’s just a couple of words (in your best, most readable handwriting), and it will help you remember what your idea is. During the workshop, it’s likely that the group will rewrite these cards as understanding forms.
3. When it’s your turn to speak, you explain to those there what your idea is, the ideas and thoughts behind it. Feel free to, at this point, sketch out something if you need to or reference an existing document or a video—whatever you need to, to build shared understanding.
4. Once you have explained that story, you place it on the map. Over the course of the workshop, things will move around as understanding forms.

Source: User Story Mapping, pp. 7-8

If you’re holding this workshop virtually, it’s a good idea to record the workshop using your video conferencing platform’s recording function.

And if you’re running this in person, take photos of everything at steps three, four, five and six. If no one’s filming the workshop and someone’s got a smartphone to hand, it would be wise to at least film a walkthrough of the map once you get to stage six and have everyone explain their thinking. This film will be helpful for software and product teams later trying to understand decisions (and help with traceability for software in more regulated sectors).

Once you’ve all gone through steps one to six, you’ll have a list of priorities that further conversations with software teams. Teams use these priorities to create actionable user stories to put in a backlog for software development and testing.

Three tips to make the most of user story mapping after the workshop

Looking to ace story mapping? Try these tips:

1. Get maps into a shareable, digital format

If you’ve hosted/held this as an in-person event, make any photos or mapping footage available digitally. Set up a project wiki or something like a SharePoint site: make sure it’s easy to access and understand. The advantage of making a text here, that links to all its parts, is that if you’re following living documentation, this mapping can be a part of it when put online.

Have you used something like Miro? Ensure the board is linked to a hub location that’s easy to find and consider linking any videos on the board or in the hub. You can even make a backup of the Miro board, downloading it and adding the file to your hub.

2. Agree on acceptance criteria with software and test teams after you map

Story mapping isn’t the last time you’ll have conversations. You’ll need to talk with your software and testing teams for one.

Those conversations might be a Three Amigos where you all agree on sprint activity (user stories). Three Amigos is usually between a product owner, a software engineer, and a test engineer. Part of this conversation will also include agreeing on acceptance criteria and forming a sprint backlog.

You’ll want to ensure that those acceptance criteria tie back to the outcomes discussed in the map. You can create user stories that hold information like the sample below either on paper or in a program like Jira or Targetprocess

3. Read the book User Story Mapping by Jeff Patton

What I’ve described in this blog post is a solid starting point. Still, there are many ways to focus and run a user story mapping workshop depending on your product or software. Jeff’s book takes you through all of these. It helps you break down, organise significant complex challenges, and understand where to go next. It’s worth reading the book.

Or at the very least, watch this video of Jeff talking about it:

User story mapping is a powerful tool

I hope this blog post has helped you realise how story mapping supports software development and how you can run a workshop for your business.

Whether you want to understand the situation with your software now or if you’re looking to the future, story mapping offers a way to share understanding so that you build the right thing. And it also helps generate evidence of development choices if your compliance needs call for that.

Do you want to work with an external embedded software team like Bluefruit Software and story map? We have helped many of our clients through a user story mapping process, so please feel free to contact us.