Template and guide for creating user story maps
Making sense of a complex user experience or feature can be difficult. You might have to work with many different functions, across multiple product teams. How do you keep things organized and make sense of it all? User story map.
What is a user story map?
Story mapping is a technique to visually breaking down complex idea into bit size pieces that can then be organized into user stories and requirements for implementation. It acts as a visual story board to help build shared understanding and keep the narrative consistent.
How to create a user story map?
Identify a problem you want to improve using “How might we [fill in the blank]”
State “who” and “why” you’re trying to tackle this problem, which frames the user and goal.
Identify activities using action verbs describing how the user solves the problem today (e.g., fill out form, get plates, review data)
Order each activity sequentially, left to right. You may need to group similar activities together if they can fall under a larger activity (e.g., make coffee, cook eggs, plate food, and eat food could all be grouped under an activity called make breakfast) .
Identify activities that are absolutely critical by move this to the top (i.e., referred to as your backbone). These are activities which cannot be changed or removed even under time pressure.
Review if there are any activities you want to change, remove, or add.
Sample User Story Map Template | Example User Story Map
Principles of good user story map
Review whether you’re mapping the current state or the future state. How do you know the difference? If everything you’ve mapped out is happening today as-is, then you’ve mapped out the current state. Time now to think what you want to change for the future state.
User story mapping doesn’t replace user story and detailed requirements just as a storyboard doesn’t replace the script or set design in a movie.
During step 3: identifying activities, you may think of ideas on how to change or remove an activity. Jot those down too, but keep them separate.
The backbone activities tells you what’s really important vs. what’s nice to have. If you have activities that isn’t in your backbone, then you know it’s not really necessary for the MVP.
While many articles talk about how you can “slice out” difference release versions by group tasks (e.g., illustrative image below), my experience tells me this is too difficult to realize. This isn’t just because you’ll likely have issues after your MVP goes live. What also occurs is major backbone activities may turn out to be entirely wrong, so version 2.0 no longer makes sense. Adjust accordingly by changing your backbone.
Source:
User Story Mapping: by Jeff Patton
User story maps: Tips and tricks to get you started fast by Eben Halford
Story Telling with Story Mapping by Mario Moreira