How to Build and Use a User Story Map

This article is translated from Jeff Patton’s blog “The New Backlog” (original URL: http://jpattonassociates.com/the-new-backlog/). Because the original post is long, it has been split into two WeChat articles: I. Problems with flat user‑story backlogs and II. How to build and use a user story map.

Building a User Story Map

We can visualize user stories as a helpful shape – a map that aids our work. A simple user story map looks like the image below:

The top level of the map is the “big story”, which I call a user activity. An activity is a large action performed by a person and may contain many steps, though not always a precise workflow. For example, when building an email system, activities might include “manage mail”, “configure mail server”, and “set up out‑of‑office auto‑reply”.

A user story for an activity reads: “As a consultant, I want to manage my mail so that I can stay in touch with clients, colleagues, and friends.” However, activities are too big to fit into a sprint.

The activity can be broken down into smaller user stories such as “send mail”, “read mail”, “delete mail”, “mark spam”, etc. I refer to these as user tasks. For many agile practitioners, a task is what is done to complete a user story; it is a step toward achieving a goal. A user task helps the user achieve a goal, while a developer task helps deliver the user story.

I place the small items (user tasks) under the larger items (user activities), forming a network‑like structure.

I always imagine time flowing from left to right. When I place user stories on the map, I put the actions that occur earlier on the left and later actions on the right, both for activities and tasks.

When teaching this method, people often ask, “What order should I place the stories on the map if users can act in any sequence?” I ask them to describe what the system is used for – just the activities. Their list determines the correct order. The sequence you describe is the correct sequence; the map tells a real story about the system.

Keep Your Epic Stories, but Stop Using That Term

True large stories can be called “epic stories”, as Mike Cohn does. They are still stories—so large they cannot be estimated or built directly. When an epic enters the backlog, it must be discussed and broken down. I dislike the term “epic story”; a simple description like “manage mail” from the user’s perspective is enough. Terms like “user activity” and “user task” are clearer for me.

Walk Your Map to Test – Get the Panorama

By walking a completed user story map with users, developers, or stakeholders, we can narrate how the user interacts with the system. We can stay at a high level or dive into details.

Walking the map helps uncover missing steps; users often point out gaps. It also highlights pain points or opportunities, as users identify current problems while we walk.

During a session with a compliance officer, we used green cards for large activities and yellow cards for small tasks. She quickly corrected a placement, showing how the visual hierarchy conveys meaning.

Building and walking a user story map makes me comfortable because I can gather information without overlooking major items.

Your Software Has a Spine and Ribs – The Map Shows Them

The top cards resemble a spine, with lower cards like ribs. The spine cards represent core capabilities of the software.

Prioritization focuses on the ribs, not the spine, because the spine’s priority is already implicit. The highest‑placed stories describe the minimum viable product (MVP) with an end‑to‑end feature set.

Plan Using the Spine

When creating a release plan, the order of spine items is often unimportant. For example, a high‑level car backlog might list Engine, Transmission, Brakes, Suspension, … The real decisions happen when we prioritize the ribs: which features are most important, what can be deferred, etc.

Prioritizing lower‑level items (e.g., 4‑cylinder vs. 6‑cylinder engine, ABS, sport suspension) is the process of building the ribs.

On the map, we move cards up or down to indicate priority, then draw swim‑lanes for each release and shift stories between lanes as needed.

Keep the Story Map for System‑Wide Communication

A user story map helps understand required functionality early on and serves as a living view of the system. It can be turned into sprint boards or iteration plans. During development, we place upcoming stories on the map, then move them to task walls as we work.

When adding features to an existing product, the spine already exists. Identifying the spine still helps place new features in context.

If a large product only needs a few new features, we may prioritize those features first, then build a small map for each, arranging about ten cards per map and laying them out left‑to‑right, top‑to‑bottom.

This Is a Pattern, Not an Invention

Although I sometimes hear complaints that the method was stolen, I recognize it as a pattern that many have independently discovered. Early work at ThoughtWorks exposed similar models.

When teaching the method, I show Indi Young’s user‑research model and Todd Warfel’s task‑analysis network, both of which arrange user behavior and features spatially.