What is user story mapping? From epic to first release
How to build a story map from user activities, break epics into stories, and slice out the smallest usable version for your first release.
Written by Phan Lam Duy Khoi
User story mapping arranges user stories in two dimensions: user activities run left to right in the order people do them, and stories sit underneath from most to least necessary. A horizontal slice across the map gives the smallest version that lets users complete the whole journey, which becomes the first release.
What is user story mapping, and when do you need it?
User story mapping arranges user stories as a two-dimensional map: user activities run left to right in the order people do them, and stories sit underneath from most to least necessary. Slice across that map and you get the smallest version that lets users complete the whole journey, which becomes your first release.
Jeff Patton described the practice in his article “The New User Story Backlog is a Map”. His central point is that a flat backlog, ordered top to bottom, loses the big picture. A map lets the team tell the story of the product in the order users live it, which makes gaps easier to see and releases easier to plan.
An illustrative situation: you have just become the PO for a booking app for a small chain of hair salons, called Hẹn Tóc. The owner hands you a single epic: “Let customers book online.” After two meetings the backlog has almost forty lines: choose a stylist, pay a deposit, reminders, loyalty points, reviews, rescheduling, revenue reports. The Developers ask a perfectly reasonable question: “What goes into the first release?” You look at the list and every line seems necessary.
Story mapping is built for exactly this moment. It does not replace the backlog. It rearranges the backlog around the user's journey, so that “what is in the first release” has an answer the whole team can see.
What is the difference between an epic and a user story?
Atlassian describes an epic as a large body of work that can be broken down into smaller stories and is usually delivered over a set of sprints. A user story is a piece small enough for the team to finish in one sprint while still giving users something useful they can see. If story writing is new to you, read the template and INVEST check in the beginner guide to user stories first.
The hard part for beginners is not the definition. It is deciding how to split the epic. “Let customers book online” could become dozens of stories, and if you split by screen or by technical layer you end up with many pieces, none of which stands on its own. A story map offers one direction: follow the steps the user takes, then ask at each step what the simplest usable version is.
In this article's view, an epic on the map usually corresponds to one large activity or one large step. The stories underneath are that epic broken apart, and their vertical order tells you which part comes first.
Why is choosing the first release so hard?
With only a long list, you can only compare lines against each other. Several things make that easy to get wrong.
- A flat list loses context. “Online deposit” and “see free slots” sit side by side as equals, even though one is a precondition for booking at all and the other can wait.
- Every item has a champion. The owner wants loyalty points, the front desk wants reminders, accounting wants reports. Each has a real reason.
- It is easy to think in features instead of users. The team talks about “the booking module” and “the payment module”, but the customer cares about one thing: is there a chair free at seven tonight.
- It is easy to split by technical layer. A plan like “sprint 1 database, sprint 2 API, sprint 3 interface” sounds tidy, but nothing reaches a user until the very end.
Agile Alliance names one concrete benefit of story mapping: it helps avoid releases that contain high-value features users cannot actually use, because those features depend on lower-value ones that were pushed back. The map exposes those dependencies before the team starts building.
How to do user story mapping, step by step
A story map has four layers. Once you know them, you can read anyone's map and build your own.
- Activities: Big things the user wants to get done, such as “book a haircut”. The top row, together called the backbone.
- Steps: Smaller steps inside each activity, in the order the user does them, such as “browse services” or “pick a time”.
- Stories: Concrete ways to support each step, hanging underneath. The more necessary, the higher it sits.
- Release slices: Horizontal lines that divide the map into releases. The top slice is the first release.
Patton compares the activity row to a backbone: these are essential parts, so they are not prioritised against each other. What gets prioritised are the stories beneath them. Here are four steps to get from one epic to a release slice.
- Agree user and goal: Who this release is for, what it lets them do
- Build the backbone and steps: Activities on top, steps below, in the user's order
- Hang stories below: A few options per step, most necessary on top
- Cut the first slice: The thinnest slice that runs left to right
After cutting, retell the journey using only stories in the first slice. Wherever it breaks, add the simplest story for that step.
Step 1: agree the user and the goal. Write one sentence: “The first release helps [who] to [do what].” For Hẹn Tóc: “Help new customers book a haircut without phoning, and help the front desk see today's bookings.” If there are several user groups, pick the most important one for the first release and map the others later.
Step 2: build the backbone and steps. Ask “what does the user do first, and then what?” and put each answer on its own card, using verbs: browse services, choose a salon, pick a time, confirm, get a reminder, change or cancel, view today's bookings. Lay the steps out in one row from left to right, then group them under a few larger activities on the top row, such as “book” or “manage the booking”. That activity row is the backbone. This is where forgotten steps can surface, for instance nobody has thought about how a customer cancels.
Step 3: hang stories underneath. Under each step, write options from the simplest to the fullest. “Pick a time” might be: see free slots for the next seven days, choose a specific stylist, book for a group of friends. Put the simplest option that still works at the top. Skip acceptance criteria at this stage; one line per card is enough.
Step 4: cut the first slice. Draw a horizontal line and keep above it only the stories needed for the user to complete the journey. Patton calls the smallest version that works end to end a walking skeleton, a term he credits to Alistair Cockburn. Each later slice thickens the steps, rather than finishing one step completely before starting the next.
Example: a story map for a salon booking app
Here is an illustrative map for Hẹn Tóc, a fictional app. Each row is one user step. Two user groups appear: customers who book and the salon's front desk staff. Read the “First release” column from top to bottom and you will see a complete journey, however basic.
| User step | Activity | First release | Next release | Later |
|---|---|---|---|---|
| Browse services and prices | Find a service (customer) | List of services with price and duration | Sample photos for each service | Filter services by price range |
| Choose a salon | Find a service (customer) | Pick from a list of salons with addresses | Suggest the salon nearest to you | See salons on a map |
| Pick a time | Book (customer) | See free slots for the next seven days | Choose a specific stylist | Book for a group |
| Confirm the booking | Book (customer) | Enter name and phone, get a booking code on screen | Account that saves details for next time | Online deposit |
| Change or cancel | Manage the booking (customer) | Confirmation screen shows the salon's phone number to call | Cancel in the app with the booking code | Move to another time in the app |
| Get a reminder | Manage the booking (customer) | Front desk messages customers from today's booking list | Automatic reminder before the appointment | Customer picks the reminder channel |
| View today's bookings | Run the salon (front desk) | List of bookings by time for each salon | Filter bookings by stylist | Weekly booking report |
A few things are worth noticing. The first slice includes manual work: customers phone to cancel, and the front desk sends reminders by hand. That is deliberate. The journey still runs end to end, while the team puts its effort into the core of seeing free slots and booking. Online deposits sit in a later slice, because customers can still book without them. Loyalty points and reviews are not part of the booking journey, so they stay off this epic's map.
Look at the front desk's “View today's bookings” step too. Without it, customers could book but the salon would not know who is coming, and the first release would be unusable. This is exactly the kind of dependency a flat list can hide.
To know whether the first slice helps, attach a measure before you build it. For example, with an assumed figure for illustration: in the first four weeks, each salon receives at least twenty bookings a week through the app, and the front desk no longer has to phone customers back to confirm times. The real number should be agreed with the owner, based on current booking volumes.
Before you commit to the first slice, run it through these four questions.
The first slice you just cut
- Can the user complete the whole journey with only the stories in this slice? Add the simplest story for the broken step, even a manual one.
- Does every story in the slice give the user something they can see? Merge technical pieces into one user behaviour.
- Is the slice thin enough to release early and learn from real users? Move non-essential stories to a later slice, or replace them with manual work.
- Is there a measure that shows whether this slice helps? Write one goal sentence and one measurable indicator before building.
Move the slice's stories to the top of the product backlog for refinement
How do you run a story mapping session with your team?
A story map is most valuable when it is built together. A PO who draws it alone and sends it round produces a map, but not the shared understanding that should come with it. Here is one way to run a first session, as this article suggests; adapt it to your team.
- Invite a few people with enough perspectives: the PO, one or two of the Developers, a designer if you have one, and someone who knows real operations (for Hẹn Tóc, a front desk person).
- Allow around sixty to ninety minutes for the first session. The aim is to go through all four steps roughly, not to finish the map.
- Prepare a whiteboard with sticky notes, or an online board. One idea per card, written large enough to read from a distance.
- Open with the first-release goal sentence, then let everyone tell the user's journey together. The PO facilitates rather than reading out a ready-made answer.
- When cutting the slice, ask the Developers which parts are surprisingly expensive. A story that looks small can drag in a lot of work, and that is information the slicing decision needs.
- Close with three things: a photo of the map, the list of first-slice stories, and the open questions, each with an owner.
After the session, the first slice's stories go to the top of the product backlog. From there they move through backlog refinement to be clarified, estimated and given acceptance criteria. When several slices and requests compete, the map gives you a base for the prioritisation conversation, and a one-page requirements document records the goal, scope and what is left out of the first release.
Story map template and session checklist
Both templates are ready to use. The first is a checklist for whoever runs the session. The second is a text skeleton of a story map that you can paste into your team's documents or use to write up the result after the meeting.
BEFORE [ ] Goal sentence: The first release helps [who] to [do what] [ ] Main user group for this release: [group] [ ] Attendees: PO, [Developers], [design], [operations] [ ] Board and sticky notes, or an online board set up [ ] Current backlog printed or open for reference DURING [ ] Read out the goal sentence [ ] Tell the journey: what does the user do first, then what [ ] Write activities and steps as verbs, left to right [ ] Hang stories under each step, most necessary on top [ ] Draw the first-slice line [ ] Retell the journey using only the first slice, fix the breaks [ ] Ask the Developers: which story costs more than it looks? AFTER [ ] Photograph the map and send it to attendees [ ] Move first-slice stories to the top of the backlog [ ] Record open questions, owners and answer dates [ ] Set a date to review the map: [date]
PRODUCT: [name]
FIRST RELEASE GOAL: Help [who] to [do what]
MEASURE: [indicator] reaches [level] after [time]
ACTIVITY 1: [verb + object]
Step 1.1: [step]
First release: [simplest usable story]
Next release: [story]
Later: [story]
Step 1.2: [step]
First release: [story]
Next release: [story]
Later: [story]
ACTIVITY 2: [verb + object]
Step 2.1: [step]
First release: [story]
Next release: [story]
Later: [story]
MANUAL WORK IN THE FIRST RELEASE:
- [task] done by [who], until [condition]
OPEN QUESTIONS:
- [question], [owner], [due date]The “manual work in the first release” section is worth keeping. It reminds the team where the first release relies on people, and when that part needs automating.
Common user story mapping mistakes
- Mapping features instead of user activities. A top row reading “Booking module, Payment module, Reporting module” is a system diagram, not a journey. Use the user's verbs: browse services, pick a time, confirm.
- Slicing by technical layer. Slice one is the database, slice two the API, slice three the interface, so nothing reaches a user until the end. Each slice should run left to right, however thin.
- Too much detail too early. Writing acceptance criteria for every card in the first session drags the meeting out and makes the map hard to change. One line per card is enough; keep detail for refinement.
- A first slice that holds everything. If the first slice includes deposits, loyalty points and reports, it is the old list redrawn. Ask of each story: without it, can the user still finish the journey?
- Drawing it once and filing it away. Revisit the map after each release, once the team has learned something from real users. Stories in later slices may move up, down, or be dropped.
- The PO drawing it alone. A map drawn by one person easily misses steps that operations staff or Developers would spot at once, such as the front desk needing to know who is coming.
Summary
- User story mapping arranges stories in two dimensions: user activities left to right, stories from most to least necessary top to bottom.
- An epic is a large body of work. The map gives you a way to split it: follow the user's steps, and start each step with its simplest usable option.
- Four steps: agree the user and goal, build the backbone, hang stories below, cut the first slice.
- The first slice must complete the journey, give users something visible in every story, be thin enough to release early, and come with a measure.
- Build the map with the team, keep each card to one line, then move the first slice's stories into the backlog for refinement.
I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.
Frequently asked questions
What is user story mapping?
User story mapping arranges user stories in two dimensions: user activities run left to right in the order people do them, and stories sit underneath ordered by how necessary they are. Jeff Patton described the practice to help teams see the whole journey and choose what to build first.
What is the difference between an epic and a user story?
An epic is a large body of work that is broken down into several smaller user stories and is usually delivered over several sprints. A user story is small enough for the team to finish in one sprint while still giving users something useful.
What is a walking skeleton?
A walking skeleton is the smallest version of a product that works end to end, even if every step is very basic. On a story map it is the first horizontal slice, and it can serve as the first release.
Sources to check
Related articles
- What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
- What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
- Prioritising the backlog when everything is urgent: How to choose between value vs effort, MoSCoW and RICE, separate real deadlines from felt urgency, and send stakeholders a one-page priority note.
- How to say no to your manager and stakeholders: Three ways to say no instead of a flat “no”, how to handle it when the request comes from your manager or CEO, when to escalate, with a sample dialogue and messages for each level.