User Story Mapping: How to Build a Map and Slice Releases

Story mapping is laying out your user stories as a map instead of a list. Across the top, left to right, go the big things a user does, in the order they do them: that row is the backbone. Under each one hang the smaller steps and details, the most necessary nearest the top. Then you draw horizontal lines across the whole map to cut it into releases, so that each release lets a user get all the way through, not just part of the way. The first slice, the thinnest version that works end to end, is called the walking skeleton.

The practice comes from Jeff Patton, who calls user story mapping↗ (opens in a new tab) “a dead simple idea”: talk about the user’s journey through your product by building a simple model of it as you go. This page is about the map. For writing a single story well, see the user story template and user story examples.

Why a map instead of a list

An ordered backlog tells you what to build next. It is bad at telling anyone what the product does, and bad at showing what is missing. In The New User Story Backlog is a Map↗ (opens in a new tab), Patton compares a team that understands its users and goals to a tree, and a flat backlog to pulling all the leaves off, bagging them and cutting the tree down: “A bag of context-free mulch.”

The second problem is releases. Build the highest-value features first and you can ship something full of good parts that still does not let anyone finish a job. Patton’s first article on the idea, It’s All in How You Slice↗ (opens in a new tab) in the January 2005 issue of Better Software, opens with exactly that release, and the customer’s verdict: “What you have is fine, but there’s not enough here for me to get my job done.” A map fixes that by making every release cross the whole journey.

The parts of a story map

• Users: who the map is about. Pick the user most critical to the product first; add others where they enter the story.
• Activities: the backbone. Patton describes an activity as “sort of a big thing that people do – something that has lots of steps, and doesn’t always have a precise workflow.” Check out, manage email, run payroll.
• Steps: the user tasks under each activity, written as short verb phrases and ordered left to right in the order you would tell the story. Enter an address, pay, get a confirmation.
• Details: the cards that hang down under each step. Patton’s story mapping quick reference↗ (opens in a new tab) lists sub-tasks, alternative tasks, exceptions and details. Higher means more necessary.
• Release slices: horizontal lines across the map. Everything above the first line is the first release.
• The walking skeleton: the first slice. Patton, borrowing Alistair Cockburn’s term, defines it as “the smallest possible system you could build that would give you end to end functionality.”

You do not prioritize the backbone. Patton’s example is a car: nobody asks whether the engine matters more than the brakes, because you need both. You prioritize what hangs under each one: four cylinders or six, anti-lock brakes or not. In his words: “I don’t prioritize the backbone. It just ‘is.’”

How to build a story map in an afternoon

1. Frame it. Write down what you are mapping, who uses it and why it matters to the business, in a few lines. A whole product or one feature both work.
2. Get the right people in the room. Patton suggests four to eight: people who know the users, people who know what earns the money, and a developer or two who know how long things take to build.
3. Map the big picture, mile-wide and inch-deep. Walk through a typical use from start to finish and write each step on a sticky note or card, left to right. Group the steps into activities once you see them.
4. Explore. Under each step, add the details: variations, what can go wrong, smaller pieces, other users. Do not argue about scope yet.
5. Walk the map. Tell the story from left to right to someone who knows the users. They will point at the gaps; Patton often hears “you’ve missed a couple steps here.”
6. Slice. Move the cards up or down and draw the release lines. Name the outcome of each slice beside it.

Sticky notes on a wall, a shared whiteboard or a spreadsheet with one column per step all work. The shape matters more than the tool: time runs left to right, necessity runs top to bottom.

A worked example: checkout for an online store

A small coffee roaster in Portland, Oregon sells bags of beans online and wants its own checkout. Three people map it: the owner, the person who packs and ships orders, and a contract developer. This is the map after an afternoon, with two release lines drawn:

ACTIVITIES   Review order     Check out ───────────────────────────────────  Get the coffee
STEPS        Review cart      Ship to          Pay              Confirm          Track package
──────────── Release 1: a customer can buy a bag, start to finish (walking skeleton) ──────────
             See items and    Enter one US     Pay by card      Confirmation     Tracking number
             total            address          Sales tax added  page and email   emailed by hand
             Change or        One flat
             remove an item   shipping rate
──────────── Release 2: fewer abandoned carts ─────────────────────────────────────────────────
             Promo code       Check the        Digital wallets  Create account   Automatic
                              address exists                    after purchase   shipping email
                              Standard or
                              express
──────────── Later ────────────────────────────────────────────────────────────────────────────
             Save for later   Address book     Gift cards       Reorder in       Text message
                              Free shipping                     one click        updates
                              over a minimum

Read Release 1 across the top and it is a whole purchase: a customer can see the cart, give an address, pay with the sales tax included, get a confirmation and receive a tracking number. It is thin everywhere. There is one shipping rate, one way to pay and no accounts. The tracking email is not even software yet; the person packing orders sends it from a saved template. Patton’s 2005 article asks exactly this of every feature left out: is there a paper process or software workaround that lets people live without it for now?

The same instinct shows up in the US government’s Digital Services Playbook, which tells teams to address the whole experience, from start to finish↗ (opens in a new tab), including the parts that happen offline. A map with a hand-sent email in its first release is doing exactly that.

Slicing releases that work

• Every slice crosses the whole backbone. A release with a great cart and no way to pay is not a release.
• Name the outcome, not the contents. “A customer can buy a bag, start to finish” tells you when the slice is done; “cart, address, payment” does not.
• Split a card rather than drop it. “Shipping” becomes “one flat rate” now and “standard or express” later.
• Slice the first release again for building. The quick reference suggests an opening game that builds the walking skeleton, a mid game that completes the major functions, and an end game that polishes for release.
• Keep the map up. It is the planning wall; the board is where the current slice gets built. When you finish a slice, go back to the map and draw the next line.

A map is not a roadmap, but its slices feed one: Release 1 is Now, Release 2 is Next, the rest is Later. The product roadmap template covers that view. Each card, once it is picked up, still needs to be written as a story with acceptance criteria.

From the map to cards on a board

Only the current slice goes on the board. Everything below the first line stays on the map, so the board’s waiting list is short and every card on it belongs to the release you are building. Two conventions keep the map’s structure once the cards leave it: start each title with its step, and label each card with its release.

On fenbs, a simple task board shared by people and AI assistants, that is one paste. Open Add many, paste the Release 1 slice, and set the project, the category “Release 1” and the lane Next Up once for the whole batch. A kind marker at the start of a line sets that line’s kind.

feature: Review cart: see items, quantities and total
feature: Review cart: change or remove an item
feature: Ship to: enter one US shipping address
feature: Ship to: one flat shipping rate
feature: Pay: pay by card
feature: Pay: add sales tax to the order total
feature: Confirm: confirmation page and email
enhancement: Track: saved email template for tracking numbers

Filter the board by the category “Release 1” to see how the slice is going; when every card is in Completed, the walking skeleton is built. The decision to cut Release 1 this thin was made by a person, so record it on the Decisions and rules page and link the tasks to it. A short AI context note describing the backbone tells any connected AI assistant where “Pay: pay by card” sits in the journey before it starts.

Be clear about what fenbs does not do. There are no epics, so the backbone is not a card; it lives on the map and in that note. There are no swimlanes, so release lines do not appear on the board. A task has one category, so the step goes in the title. And there are no due dates, so a release date is kept on your calendar, not on the board.

Common story mapping mistakes

• Mapping the system instead of the user. “Sell items at point of sale” describes what a person does; “the system supports EAN-13 barcodes” describes a thing. Patton’s 2005 article asks for the first kind, starting with an action verb.
• Prioritizing the backbone. Rank what hangs under it instead.
• A first release made of the best parts, not a whole path. If a user cannot finish the journey, it is a demo.
• Throwing the map away after planning. Patton keeps it on the wall, where it becomes the team’s planning board and “a constant point of discussion about the product we’re building.”
• Mapping a whole product for one small feature. For a few new features, build a little map for each, often about ten cards, and slice that.