Speaking Engineering: Disambiguation Frameworks for Business Owners
Module 6 of 7 Intermediate 25 min

The User's Journey, Made Visible — User Story Mapping for Delivery Planning

Prerequisites: When Everyone Means Something Different — Why Disambiguation Matters, Reading the Room — How Event Storming Surfaces What Actually Happens

What You'll Learn

  • The three-level structure of a user story map — Activities, Steps, and Stories — and the role each level plays.
  • How a user story map differs from a flat backlog, and why the map preserves what the backlog destroys.
  • How to use a release line (a horizontal cut across a user story map that groups which stories go into a given release or iteration) to define what "done enough for launch" actually means.
  • How user story mapping follows from — and uses the outputs of — an event storming session.
  • How to sketch a simple user story map for a business process you own.

Why This Matters

This framework resolves the ambiguity of what users experience and in what order we build it by making the user journey visible and shared across teams.

You have probably sat through a project kickoff where the team agreed, at a high level, on what the product would do — and then three months later discovered that engineering built something technically correct but experientially wrong. The user could complete individual steps, but the whole journey felt broken. Features were missing at exactly the moments users needed them most. That gap between "what we agreed to build" and "what a user actually experiences" is what a user story map — a visual, two-dimensional grid that organises user activities horizontally and details vertically to preserve the user journey while enabling release planning — is designed to close. It is not a planning tool for engineers. It is a shared artefact for everyone who needs to agree on what a user's journey looks like and what version one of that journey will include.

Core Concept

Jeff Patton created user story mapping to solve a specific, painful problem: teams were writing user stories — short descriptions of what a user needs to do — and collecting them into flat backlogs, but in the process losing the thread that connected those stories. A backlog is a list. A list has no shape. It cannot tell you whether a set of stories adds up to a coherent experience or a pile of disconnected features.

A user story map restores the shape. It is two-dimensional on purpose.

The three levels of a user story map

The map has a horizontal axis and a vertical axis, and they mean different things.

  • Activities run across the top of the map. An activity is a broad user goal — the large-grain things a user sets out to accomplish. For a Sales agent at Meridian Insurance, the activities might be: Browse Products, Get a Quote, Submit Application, Receive Decision, and Bind Policy. Read left to right, these activities tell the story of the agent's full journey. They are the chapters of the book.

  • Steps sit just below each activity. A step is a key moment within that activity — a concrete action the user takes to accomplish it. Under "Submit Application," the steps might be: Gather business details, Attach documents, Confirm coverage selections, and Submit. Steps are still horizontal: they read left to right in the order the user encounters them.

  • Stories (or details) stack vertically beneath each step. These are the specific tasks that need to be built to make that step work. Under "Attach documents," one story might be "Upload certificate of occupancy" and another might be "Upload optional supporting photos." The critical stories sit at the top; the less essential ones sit lower.

The vertical axis is the prioritisation axis. The higher a story sits in a column, the more essential it is to the user's experience of that step. Stories below the line can be deferred. Stories above it must be in the release.

The release line

This is where user story mapping becomes a delivery planning tool. Once the map is built, the team draws a horizontal line across the entire map — the release line. Everything above the line goes into the first release. Everything below is deferred.

The release line is not drawn by engineering alone, and it is not drawn by the business alone. It is drawn collaboratively, because it forces a real conversation: what does "done enough" mean? Can a Sales agent complete the full journey — end to end — if we only build the stories above this line? If yes, the line is in the right place. If the agent would get stuck halfway through their journey, the line needs to move.

You can draw multiple release lines for multiple releases. Release 1 gets the agent through the core journey. Release 2 adds convenience features. Release 3 adds reporting and edge cases.

What user story mapping follows from

User story mapping is a delivery organisation tool. It answers the question: given that we know what the user's journey looks like, in what order do we build it? This means it works best after you already understand the journey.

If your team runs event storming first — as Meridian's team did in Module 03 — the domain events discovered in that session become natural inputs to the story map. "Quote Requested," "Risk Assessed," "Policy Issued," "Premium Collected," "Claim Filed" — these domain events mark the significant moments in the business process. In a story map, they become the milestones that anchor the Steps row. Event storming is discovery; user story mapping is delivery organisation.

You can also run a story map without prior event storming, especially when you already know the user journey well and the main challenge is sequencing what to build first. The two techniques are complementary, not codependent.

Concrete Example

Let's walk through how Meridian Insurance's product team builds a story map for the Sales agent journey, using the domain events from their earlier event storming session as the spine.

Step 1: Set the activities across the top

The team writes five activity cards along the horizontal axis, left to right:

  1. Browse Products
  2. Get a Quote
  3. Submit Application
  4. Receive Decision
  5. Bind Policy

This is the Sales agent's full journey from first interest to active policy. Each card is a chapter.

Step 2: Add steps beneath each activity

Under "Submit Application," the team writes four steps:

  1. Gather business details
  2. Attach documents
  3. Confirm coverage selections
  4. Submit

Under "Receive Decision," the steps are:

  1. Review underwriting decision
  2. Accept or request revision

Step 3: Stack stories beneath each step

Under "Attach documents," the team places two story cards:

  • "Upload certificate of occupancy" — this is mandatory; without it the application cannot proceed.
  • "Upload optional supporting photos" — helpful but not required.

The mandatory story goes higher; the optional one goes lower.

Step 4: Draw the release line

The product director draws a horizontal line across the map beneath the most essential stories in each column. Everything above the line is Release 1.

Looking at "Submit Application" → "Attach documents": "Upload certificate of occupancy" sits above the line. "Upload optional supporting photos" sits below.

Looking at "Bind Policy": the entire activity sits below the line for Release 1. It moves to Release 2.

Now Sales has a clear picture. In Release 1, a Sales agent can browse products, get a quote, submit an application (including uploading the required certificate), and receive an underwriting decision. They cannot yet bind the policy digitally — that comes in Release 2.

This directly resolves the scoping ambiguity from Module 01. Remember the Meridian product launch, where engineering built an "approval" workflow that meant something different to each team? The story map makes the scope of Release 1 explicit and visible. There is no room for each team to imagine a different version of "done."

Analogy

Think of the difference between a road atlas and a bucket of road signs.

A road atlas shows you the whole route. You can see where you start, the towns you pass through, the point where you turn, and where you end up. If you need to cut the trip short, you can look at the map and find a sensible stopping point — a town with a hotel and a petrol station, not a junction in the middle of nowhere.

A flat backlog is a bucket of disconnected road signs. Each sign is individually accurate: "Exit 12," "Speed limit 70," "Toll plaza ahead." But thrown in a bucket, they tell you nothing about the route. If you need to cut work short, you have no way of knowing whether the stories you are deferring will leave users stranded mid-journey.

A user story map is the road atlas. It shows the whole route. The release line tells you where you are planning to stop on the first trip. And because everyone can see the map, everyone can have a meaningful conversation about whether that stopping point makes sense.

Going Deeper

The "thin slice" release strategy

The release line does not have to cut horizontally across a single group of steps. Some teams use a "thin slice" approach: instead of building all the steps for one or two activities fully, they build one thin story from every activity — just enough to prove the end-to-end journey works. For Meridian, a thin slice release might include only the minimum story from each of the five activities, so a Sales agent can technically complete the entire journey, even if each step is rough. This is useful for validating the architecture and the end-to-end flow before investing in the full depth of any single activity.

User story mapping and the impact map

In Module 05, Meridian's product director used an impact map to establish the goal ("1,000 small business policyholders in 12 months"), identify the actors (Sales agents), and define the key impact ("submit complete applications without back-and-forth"). The user story map then details the "how" of delivering that impact. Together, impact mapping answers "why are we building this?" and user story mapping answers "what exactly are we building and in what order?" Using both gives you a chain from goal to journey to delivery.

When user story mapping is not the right starting point

User story mapping assumes the team already has a reasonable understanding of the user's journey. If the process is largely unknown, or if there is deep disagreement about what actually happens in the business, event storming is the better first step — it is a discovery tool. Use event storming to surface the domain events, then use user story mapping to organise them into a delivery plan. If the underlying disagreement is about business goals rather than user journeys, start with impact mapping. The story map is most powerful once the "why" and the "what happens" are reasonably settled.

Jeff Patton's original insight

Jeff Patton developed user story mapping in the mid-2000s, working with Agile teams who were struggling with exactly this problem: their story-writing practice was creating lists that nobody could navigate. He published his ideas in a 2005 article and expanded them into his book "User Story Mapping: Discover the Whole Story, Build the Right Product" (O'Reilly, 2014). The core argument — that a story without a narrative context is nearly useless — remains as relevant as ever. Patton's contribution was not the sticky note; it was insisting that the user's story, told from beginning to end, must stay visible throughout delivery.

Common Misconceptions

Misconception 1: "User story mapping replaces the backlog."

This is the most common and most consequential misunderstanding. A user story map is not a replacement for the backlog — it is the source that generates the backlog. The map is a discovery and alignment tool: it lets the team see the full user journey and make deliberate decisions about what to build first. Once those decisions are made, the stories above the release line are moved into the backlog for sprint execution. The map stays on the wall as the shared reference point; the backlog is the flat execution list derived from it. Teams that throw away the map after extracting backlog items lose the ability to reason about whether their work adds up to a coherent user journey.

Misconception 2: "The horizontal order is the build order."

The horizontal axis of a story map shows the user's logical journey — the order in which activities and steps occur in the user's experience. It does not dictate the order in which engineering must build them. Teams routinely build features in a different sequence for technical or dependency reasons. The map is about the user's sequence of experience, not the engineering sequence of construction. If your team needs to build the document upload capability before the quote flow for technical reasons, that is fine — the map does not constrain the build order.

Misconception 3: "User story mapping is only for digital products."

User story mapping was invented in the context of software development, but the technique works for any process where a person moves through a sequence of steps to accomplish a goal. HR onboarding, insurance claims handling, sales pipeline management — any business process with a clear user journey can be mapped this way. For a non-technical business owner, this means you can use user story mapping to clarify and sequence operational improvements, not just software features. The Meridian Claims team, for instance, could use a story map to redesign their settlement process even before a single line of code is written.

Check Your Understanding

  1. In a user story map, what is the difference between the horizontal axis and the vertical axis, and what does each one tell you?
Reveal answer The horizontal axis represents the user's journey through time — Activities read left to right as the sequence of broad goals, and Steps read left to right as the sequence of moments within each goal. The vertical axis represents priority — stories higher in a column are more essential; stories lower are less essential and candidates for deferral. The horizontal axis answers "what happens in what order?" and the vertical axis answers "what is essential vs. nice to have?"
  1. Meridian's product team has drawn a release line across their story map. When they review it, they notice that under the "Receive Decision" activity, only the story "Review underwriting decision" sits above the line — but "Accept or request revision" sits below it. What problem does this create for a Sales agent, and what should the team do?
Reveal answer A Sales agent who can view the underwriting decision but cannot accept it or request a revision is stuck — they cannot complete the journey. This is exactly the kind of broken experience that the release line conversation is meant to surface. The team should either move "Accept or request revision" above the release line (committing to build it in Release 1) or acknowledge that the Release 1 journey is incomplete and plan accordingly — perhaps handling acceptance through a manual workaround for the first release. The map makes this tradeoff explicit rather than discovering it after launch.
  1. How do the domain events from an event storming session connect to the structure of a user story map? Use the Meridian example.
Reveal answer Domain events mark significant moments that happened in the business — they are the milestones of the business process. In a story map, these milestones become natural anchors for the Steps row. For Meridian, the event storming session surfaced events like "Quote Requested," "Risk Assessed," "Policy Issued," and "Premium Collected." In the story map, these events map directly to steps within activities: "Quote Requested" sits under "Get a Quote," and "Policy Issued" sits under "Bind Policy." Event storming surfaces what actually happens; user story mapping organises those happenings into a delivery plan.
  1. Why does flattening a user story map into a backlog lose important information? What specifically is lost?
Reveal answer When you flatten a map into a backlog, you lose the narrative structure — the visible connection between each story and the step it belongs to, the step and the activity it serves, and the activity and the overall user journey. A flat backlog shows you a list of tasks; it cannot show you whether those tasks add up to an experience where a user can accomplish their goal from start to finish. If a critical step is missing from the list, the backlog gives you no way to notice. The map makes that gap immediately visible because the journey is always in front of you.
  1. A colleague says: "We should build our user story map before we do event storming — that way the map can guide the event storming session." What is wrong with this reasoning, and in what order should the two techniques typically be used?
Reveal answer The reasoning has the dependency backwards. Event storming is a discovery tool — it surfaces what actually happens in the business by finding domain events. User story mapping is a delivery organisation tool — it takes a known user journey and organises it for release planning. If you build the story map before event storming, you are mapping a journey you have assumed rather than discovered. Important events, handoffs, and ambiguities that event storming would have surfaced will be missing from your map. The correct sequence is to use event storming first to discover the business process and its domain events, then use user story mapping to organise those events into a user journey and plan delivery. You can run a story map without prior event storming — but only when the journey is already well understood.

Key Takeaways

  • A user story map is two-dimensional: Activities and Steps run horizontally to tell the user's journey; Stories stack vertically by priority beneath each step.
  • The release line is a deliberate, collaborative decision about what "done enough for launch" means — it is drawn across the map to group which stories belong in which release.
  • A flat backlog is derived from the map, not a replacement for it; once you flatten the map, you lose the narrative context that lets teams see whether their work adds up to a coherent user experience.
  • Event storming discovers the business process and its domain events; user story mapping organises those events into a delivery plan. The two techniques are complementary, with event storming feeding the map.
  • You can run user story mapping without prior event storming when the user journey is already well understood — but the combination of both gives you the strongest foundation for delivery planning.

References