User Story Mapping: A Quick Start Guide

hala saleh
Jul 12, 2017 · 7 min read
UX, Product, and Engineering mapping stories

If you build products that end up getting used by users, you may have heard of User Story Mapping. If you haven’t, and you care about those users’ experiences with your product and want that experience to provide value, then you definitely want to look it up.

You may have also heard of Jeff Patton, who coined the term and has done the Product Managers, UX designers, and Engineering teams of the world a great service by documenting this process and its benefits in his book, User Story Mapping: Discover the Whole Story, Build the Right Product. If you haven’t already, go get yourself a copy. You will thank me for it. But mostly, you’ll thank Jeff.

I’ve recently been working with a colleague and overall UX badass, Stephanie German, to get teams familiar with and trained on the User Story Mapping process, and although you definitely want to read Jeff Patton’s book and blog posts about the details, we found it valuable for ourselves to create a Quick Start Guide that gets some of the initial logistics out of the way and ensures you get started off on the right foot.

If you’ve been wanting to utilizing story mapping with your teams, but you’re not feeling quite confident that you have a consistent Let’s-Get-This-Show-On-The-Road process, we hope this guide is helpful to you. (Note: This has not been endorsed or reviewed by Jeff or any other story mapping experts, it’s just what works for us.)

User Story Mapping: A Quick Start Guide

Story Map

Congratulations, friend! You are on your way to leading an amazing user story mapping session!

Here’s what you need to start.

Before the session:

  • Ensure you have representation from UX, Product, and Engineering.
  • Determine whether or not you will have mockups or wireframes to help walk through the user’s flow through the system.
  • If no UI mocks/ wireframes, have the team prepare ahead of time to be able to speak to the flow.

Room Setup:

Make sure to cover general setup of the room:

  • Whiteboard + markers
  • Big post its (enough for the whole room)
  • Little post its (enough for the whole room)
  • Big tearable sticky charts can be helpful when you don’t have a lot of whiteboard space available
  • Parking Lot — explain this is where to put questions or topics that come up that may be more suitable for the end of the mapping or handled offline afterwards
  • Determine and communicate how many hours people will be in the room, and set expectations for breaks/ lunch/ etc.

Kicking Things Off:

  • Explain to people why they’re here. (To create a better, more visual model and representation of a product backlog that is centered around the user and their experience, TOGETHER, of course!)
  • Cover the basics of user story mapping, why it’s useful, what it is you are trying to achieve over the next X amount of hours/days.
  • Describe or have someone in the team describe the business problem/ opportunity you are trying to solve.
  • Explain the importance of everyone participating and adding their voice.
  • In some cases, it can be helpful for Product/UX/Business teams to share a presentation/ overview with the group to get people on the same page.

Getting to Work:

Go through an exercise with the team where you have them break down the opportunity and the goals of the project at a high level

  • What is the problem/ opportunity?
  • What are we trying to solve/ create?
  • Who are we solving the problem for? (Try to be specific. Please don’t say “everyone”)
  • What does the company benefit from this change?
  • What does the customer benefit from this change?
  • What does the user benefit from this change? (The customer is not always the user. Tricky tricky.)
  • What are our success metrics?

System/ Page Flow

  • This is where things get fun. Encourage the team to get up on the board and start creating a flow of the system/ pages that the user will go through from start to finish when interacting with the product.
    This doesn’t necessarily have to be a “page flow” if you are not building an Internet product/ website, but rather, a logical flow of activities the user will go through while interacting with your product.
  • If you are going through this process by utilizing a logical “page flow” through your system, it can help to tape/ put up the mock or wireframe for each of the pages in turn, or just creating a big post-it or spot on the wall that represents that page.
  • “Job” of each page: Once the flow is up on the wall, talk about the “Job” of each page. Why does it exist? What functionality should be there on that page? This is a good opportunity to ensure that pages’ “jobs” are not overlapping or redundant.
  • Discuss whether there are edge cases or weird scenarios (weird being a technical term here, ahem) for the page flow that are not covered by the main path.

User Story mapping

  • Divide the room into 3 or 4 groups, depending on the size of the team.
  • For each group, have them take one of the pages and break that page down into user stories. These stories should cover the main functionality of that page from a user perspective, but can also include developer/ tech/ backend stories, as well as Analytics stories, etc. Give each group a set amount of time to work on stories so they know when you will be re-grouping. (20–30 minutes).
    Protip: You will know it’s “time” to end the user story brainstorming awesomeness when the volume and energy of the room start dwindling, people start checking their smartphones (which should be BANNED, of course), and asking when the next coffee break is going to be.
  • Once each of the pages in the flow is covered, start to review the stories for each page together as one large group.
    Have someone from each of the groups come up and read the stories for that page, answering questions from the team, clarifying, etc.
  • Encourage people to note important clarifying points, call-outs, exception cases, etc. on smaller post-its and append to the stories if necessary, or just add directly to the story.
  • Sometimes when going through the stories this way, the team realizes that there are more stories to add for a page, or that stories need to be re-written. Give them additional time to cover these and write them down.

Release Planning:

Now that you have the stories down for each page/ user activity, you can divide stories into releases.

  • The idea is that the first release(s) will start to prove some of the higher risk questions you have for the project — maybe it’s a new technology the team is building on, so the most important stories for the first release will be to prove out the infrastructure/ technology, or maybe it’s more of a UI focused project, and it will be important to ensure they have a good implementation of the front-end.
  • Whatever that ‘highest risk’ item is, work with the team to prioritize what they want to prove incrementally and iteratively, and encourage them to have a slice of end-to-end functionality if possible with each ‘release’.

What is the goal of each release/iteration?

  • Remind the team that releases don’t necessarily need to be released to production, they are just a way to slice up the work in a way that makes sense and allows them to have a specific goal/ objective for each release.
  • Once you have determined the goal of each release with the team, start to create horizontal lines along the wall, and have the team come up to the board and put stories that are included in the first release above the line. You can create as many horizontal lines on the board (painter’s tape is great for this) as you need releases.
  • Your role here is to remind the team of the main goals and objectives for each release, and keep them focused on those as they include/ exclude stories from each release. Remind them of the goal of the release/ iteration and ask if stories are contributing to that goal.

Estimation/ Sizing:

At this point, the team can probably come up with really rough estimates/ sizing for the work required to implement the stories for each release.

  • The most important release to start estimating/ sizing at a high level is the first one. Once they start working on release 1, they will learn a lot of stuff they did not know when starting out, which will probably change the estimates for subsequent releases.
  • Encourage the team to work together to come up with high level estimates (t-shirt sizes or fibonacci, however they typically estimate their backlogs), to be able to set expectations with product on the general “size” of the project.

Next Steps:

  • From here, the team has a set of high level goals for each release. What they need to do now is create stories they can work off of for the 1st release.
  • Explain to the team that they can now take the stories for the first release/ iteration, go back to the rest of their team, break those stories down further in the tool of their choice, and start to groom/ organize those stories.
  • Once this is done, the team can start to plan their first sprint (or put stories in their Kanban board, if that’s how you roll), and get working!

We’d love your feedback and comments! As always, building products is a process of continuous improvement, and we’d love your insights on what works for you.

hala saleh

Written by

People-driven Products, Sunrise/sunset and light chaser. Always learning.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade