How to Do Story Mapping: Identifying User Activities and Building the Story Backbone
This skill teaches you how to define the top-level user activities for a story map and arrange them in chronological order to create the horizontal backbone that structures all subsequent decomposition and prioritization.
Start by listing every high-level activity a user performs to accomplish their goal with your product. Write each activity on a sticky note or card, then arrange them left to right in the order users typically perform them. This chronological row of activities becomes the backbone, the top-level horizontal spine that anchors every user task and story beneath it. Aim for 4-8 activities that span the full user journey from first trigger to final outcome.
Outcome: You produce a validated horizontal backbone of 4-8 chronologically ordered user activities that serves as the structural foundation for the entire story map, enabling your team to decompose tasks, prioritize releases, and maintain a shared understanding of the user journey.
Prerequisites
- Basic understanding of user stories and who your target users are
- Familiarity with the overall Story Mapping framework and its purpose
- Access to a whiteboard, wall space, or a digital collaboration tool like Miro or FigJam
- A clearly defined product scope or user goal to map against
Overview
The backbone is the single most important structural element of any story map. It is the horizontal row of high-level user activities arranged in the order a user performs them, stretching from the initial trigger ("I need to do X") through to the final outcome ("I have accomplished X"). Every user task, story, and detail in the map hangs beneath this backbone. If the backbone is wrong, incomplete, or out of order, every subsequent layer of the map will inherit those errors. Getting the backbone right is the first concrete step in learning how to do story mapping well.
This skill sits at the very beginning of the Story Mapping workflow. Before you can decompose activities into tasks and stories or prioritize and slice releases, you need a backbone that the entire team agrees represents the real user journey. The backbone is not a feature list, not an org chart of your product's modules, and not a technical architecture diagram. It is a narrative, a story told from the user's perspective about what they do and in what sequence.
The concrete artifact you produce is a single horizontal row of 4-8 activity cards, each labeled with a verb-noun phrase ("Search for flights," "Compare options," "Complete booking"), arranged left to right in chronological order. This row should be readable as a sentence: "First the user does X, then Y, then Z, and finally W." When the team can walk along the backbone and nod in agreement that this is how the journey actually unfolds, you have a foundation strong enough to support the entire map. The backbone also becomes a communication tool for stakeholders who want the big picture without the detail, and a navigation aid for teams who need to locate where a given feature or story belongs within the broader journey.
A well-constructed backbone typically takes 45-90 minutes to draft and validate with a small cross-functional group. The time investment pays dividends immediately: alignment improves, scope conversations become grounded in user reality rather than internal assumptions, and every future story mapping session starts from a shared reference point rather than a blank wall.
How It Works
The backbone works because it imposes a narrative constraint on product thinking. Without it, teams tend to organize features by technical system, business unit, or sprint backlog, none of which reflect how a user actually experiences the product. The backbone forces a shift to the user's perspective by asking one deceptively simple question: "What does the user do, and in what order?"
Each activity on the backbone represents a chunk of user behavior that is big enough to contain multiple tasks but small enough to be distinct from neighboring activities. Think of activities as chapters in a book. "Onboarding" is a chapter. "Clicking the signup button" is a sentence inside a paragraph inside that chapter. The right altitude for a backbone activity is the chapter level. You should be able to explain the entire user journey in one breath by reading the backbone left to right.
The chronological arrangement matters because it mirrors how users think about their own experience. Users do not think in feature categories. They think in sequences: "First I need to find the thing, then I need to evaluate it, then I need to buy it, then I need to set it up." By mapping to this mental model, the backbone becomes intuitive for anyone on the team to read, regardless of their role. It also exposes gaps. If you lay out your activities and notice a jump from "Search for product" to "Receive delivery," the absence of selection, checkout, and payment activities becomes immediately visible.
The backbone also serves as the primary axis for the Story Mapping framework's two-dimensional structure. The horizontal axis (the backbone) represents the narrative flow. The vertical axis, which you build later, represents priority and detail. This two-axis structure is what differentiates story mapping from a flat backlog. A flat backlog is a one-dimensional list. A story map is a landscape with geography, and the backbone is the horizon line that gives that landscape its orientation.
One important mental model: the backbone is stable but not permanent. It should change infrequently, perhaps when you discover a major workflow you missed or when the product scope fundamentally shifts. But within a release cycle, the backbone acts as a fixed reference. Tasks and stories beneath it will move, get re-prioritized, and get split. The backbone stays. This stability is what makes it useful as a coordination tool across multiple teams and sprints. When someone asks "where does this new feature go?" you point to the backbone activity it belongs under, and the answer is immediately clear.
Step-by-Step
Step 1: Define the Target User and Their Primary Goal
Before writing a single activity, articulate who the user is and what they are trying to accomplish end to end. " This sentence becomes your scope boundary. Every activity you identify must serve this goal. If an activity does not contribute to the user reaching this outcome, it does not belong on this backbone.
Gather the team around this statement and confirm agreement before proceeding. If your product serves multiple user types with fundamentally different journeys, pick one and build a separate backbone for each. Mixing personas on one backbone creates confusion about whose journey you are mapping.
Tip: If the team struggles to agree on the goal, it usually means you have multiple user segments mixed together. Split them. A backbone for 'new user onboarding' and a backbone for 'power user daily workflow' will each be more useful than one backbone trying to cover both.
Step 2: Brainstorm All Candidate Activities Individually
Give each participant 5-7 minutes of silent brainstorming to write down every high-level thing the user does to achieve the goal you defined. Each activity goes on its own sticky note or card. " Do not discuss or filter during this phase. The goal is divergence, getting as many candidate activities on the table as possible.
Encourage participants to think about the full journey, including steps that happen before they touch your product (the trigger) and steps that happen after (the outcome or follow-up). A common failure mode is to only brainstorm activities that correspond to existing features. Remind the group that the backbone maps what the user does, not what your product currently supports.
Tip: Silent brainstorming before group discussion prevents anchoring. The loudest voice or most senior person in the room often sets the frame, and everyone else edits around it rather than contributing genuinely different perspectives.
Step 3: Cluster and Merge Duplicate Activities
Collect all the sticky notes and place them on the wall or board. Read each one aloud. Group duplicates and near-duplicates together. If three people wrote "Find a car," "Search inventory," and "Browse listings," those represent the same activity.
Choose the label that best captures what the user is doing at a level the whole team understands. Discard labels that are too granular (those will become tasks in the next skill) or too abstract. "Use the product" is too abstract. "Click the filter dropdown" is too granular.
"Filter search results" is about right for a task, but "Search for a car" is the activity-level version. After merging, you should have somewhere between 6-15 candidate activities. If you have fewer than 4, you are probably too abstract. If you have more than 15, you are probably mixing activities with tasks.
Tip: A quick test for the right altitude: can you imagine spending an entire user session on this one activity? If yes, it is an activity. If a user would do it in under 30 seconds, it is probably a task that belongs one level down.
Step 4: Arrange Activities in Chronological Order
Take your merged set of activities and arrange them left to right in the order a user would typically perform them. Start with the trigger activity on the far left and end with the outcome or completion activity on the far right. " This narrative should feel like a plausible story. If the sequence feels forced or if activities seem interchangeable in order, consider whether two activities actually happen in parallel or whether one of them is optional.
It is fine to have optional activities on the backbone. Note them with a visual marker, but keep them in the position where they most commonly occur.
Tip: Some journeys are not strictly linear. Users may loop back (search again after comparing) or skip steps. Map the most common happy path first. You can annotate loops and branches later, but the backbone should represent the primary flow.
Step 5: Trim to 4-8 Core Activities
A backbone with more than 8 activities becomes hard to use as a navigation tool. It loses the "one breath" readability that makes it powerful. Review your ordered sequence and look for activities that can be combined. " Alternatively, look for activities that are really tasks belonging under a neighboring activity.
"Read reviews" might belong under "Compare options" rather than standing on its own. Your goal is a backbone of 4-8 activities. On the low end, 4 activities work for simple workflows like a signup flow. On the high end, 8 activities work for complex multi-session journeys like an enterprise procurement process.
If you are stuck at 10 or more, you are likely mapping a journey that should be split into two separate story maps, each with its own backbone.
Tip: A useful forcing function: tell the team they get exactly 6 cards. Having to choose forces the conversation about what is truly a top-level activity versus what is a sub-step.
Step 6: Validate the Backbone Against Real User Behavior
The backbone is a hypothesis about how users experience your product. Before treating it as settled, validate it. Walk through the backbone with someone who has direct user contact: a support agent, a sales rep, a researcher. " Look specifically for missing activities (steps users take that the team forgot), phantom activities (steps the team assumed users take but that rarely happen in practice), and ordering errors (steps that happen in a different sequence than the team assumed).
If you have access to analytics, session recordings, or user research transcripts, cross-reference those. A 15-minute validation pass can save hours of rework later. Common discoveries at this stage include realizing that users spend significant time on an activity the team considered trivial, or that a step the team thought was sequential actually happens much earlier.
Tip: If you have session recordings from tools like FullStory or Hotjar, watch 3-5 recordings of new users completing the journey. The discrepancy between what the team assumes and what users actually do is almost always revealing.
Step 7: Label and Document the Final Backbone
Once validated, create clean final versions of each activity card. Each card should have a clear verb-noun label, a one-sentence description of what the user is doing and why, and optionally a note about the user's emotional state or key concern at that point in the journey. " Document the backbone in whatever tool your team uses for story mapping, whether that is a physical wall, Miro, FigJam, or a dedicated tool like StoriesOnBoard. Take a photo of the physical version if applicable.
This documented backbone becomes the starting point for the next skill: decomposing activities into user tasks and stories.
Tip: Adding the user's emotional state or key question at each activity is not required, but it dramatically improves the backbone's usefulness for design and prioritization conversations later.
Examples
Example: E-Commerce Mobile App (Small Startup Team)
A 5-person startup is building a mobile app for buying vintage clothing. The team includes a product manager, two engineers, a designer, and a part-time marketer. They have 30 minutes for backbone creation during a sprint planning session. Their target user is a fashion-conscious millennial browsing on their phone during commute time.
" Each person silently writes activities on sticky notes for 5 minutes. They generate 18 cards total. After clustering duplicates, they have 11 candidates: Discover the app, Browse collections, Search for specific items, View item details, Save favorites, Check sizing, Add to cart, Enter payment, Confirm order, Track delivery, Leave a review. " The final backbone has 6 activities: Explore inventory, Search for items, Evaluate item, Purchase item, Track delivery, Share feedback.
They read it aloud as a story and it flows naturally. The designer notes that the user's biggest anxiety is at "Evaluate item" because sizing for vintage is unpredictable. This annotation is added to the card. The entire exercise takes 25 minutes.
Example: B2B SaaS Onboarding Flow (Mid-Size Company)
A B2B project management tool company with 40 employees wants to map the onboarding journey for new team administrators. The product team of 8 people runs a dedicated 90-minute backbone workshop. Their target user is an IT administrator at a 200-person company who has been tasked with rolling out the tool to their organization.
" Silent brainstorming produces 26 candidate activities across 8 participants. After clustering, 14 distinct activities remain. The team notices that many activities map to their product's settings pages rather than user goals. " The team settles on 7 backbone activities: Evaluate the tool, Get organizational buy-in, Configure the workspace, Import existing data, Invite and onboard team members, Establish workflows, Monitor adoption.
The customer success lead flags that "Get organizational buy-in" often happens before the admin ever signs up, confirming it belongs on the backbone. She also notes that "Monitor adoption" is frequently skipped, leading to failed rollouts, making it critical to keep visible. Validation against 5 recent onboarding support threads confirms the ordering and reveals that "Import existing data" is a much bigger pain point than the team assumed, which changes how they will prioritize tasks beneath that activity.
Example: Consumer Health App (Large Cross-Functional Team)
A health tech company with 200 employees is redesigning their diabetes management app. The product team runs a half-day story mapping workshop with 12 participants: product managers, clinicians, engineers, designers, and a patient advocate. Their target user is a newly diagnosed Type 2 diabetes patient learning to manage their condition.
" Given the large group, they split into three sub-teams of 4 for silent brainstorming, generating over 40 candidate activities. " After clustering across all three groups, 16 candidates remain. The group uses dot voting to identify the 8 most essential activities. The final backbone: Learn about diabetes, Set up monitoring routine, Log daily meals and activity, Check blood sugar readings, Identify patterns, Consult care team, Adjust management plan, Track long-term progress.
The patient advocate validates this against her own experience and flags that "Learn about diabetes" is not a one-time activity but recurs throughout the journey. The team decides to keep it as the first backbone activity representing the initial learning phase, with a note that educational content surfaces contextually under other activities as well. Reading the backbone aloud, the group agrees it tells a coherent story. The clinician observes that the emotional weight shifts dramatically from left (fear, confusion) to right (confidence, routine), and these emotional annotations are added to each card for future design reference.
Example: Internal Tool for Operations Team (B2B, No External Users)
An operations team at a logistics company wants to map the journey for their internal dispatchers who use a custom-built routing tool. The team of 4 (ops manager, two dispatchers, one developer) has 60 minutes. The user is a dispatcher managing 50-80 deliveries per shift.
" Because the dispatchers are in the room, brainstorming is grounded in reality from the start. They generate 12 candidate activities. The dispatchers immediately flag that the developer's suggestions ("Log into system," "Check system status") are system-level, not user-level activities. After merging, 8 activities remain: Review incoming orders, Plan delivery routes, Assign drivers, Communicate route details, Monitor active deliveries, Handle exceptions and re-routes, Close out completed deliveries, Report shift summary.
One dispatcher points out that "Handle exceptions" is not a sequential step but happens continuously throughout the shift. The team places it in the position where it most commonly first occurs (after monitoring begins) and annotates it as a recurring activity. The backbone is validated by walking through yesterday's actual shift log. The ops manager discovers that "Communicate route details" takes far more time than anyone on the product side realized, suggesting an automation opportunity.
The final backbone of 8 activities fits naturally because the dispatcher workflow is genuinely complex with distinct phases.
Best Practices
Always write activities as verb-noun phrases from the user's perspective, not from the system's perspective. "Search for listings" is correct. "Display search results" describes what the system does, not what the user does. This distinction matters because the backbone should be readable by anyone, including non-technical stakeholders, as a story about the user's experience.
When activities are written in system language, the backbone drifts into a technical specification and loses its power as a shared communication tool.
Keep the backbone between 4 and 8 activities. Fewer than 4 means you are too abstract and the backbone will not provide useful structure for decomposition. More than 8 means you are mixing activity-level items with task-level items, and the backbone will become cluttered and hard to use as a navigation reference. If you consistently land above 8, check whether you are mapping a journey that should be split into two separate maps.
Start the backbone before the user touches your product and end it after they have achieved their goal. The first activity should capture the trigger or need that initiates the journey, and the last should capture the outcome or follow-up. This prevents the common trap of only mapping activities that correspond to existing features, which blinds the team to opportunities at the edges of the journey where users are currently underserved.
Do not skip the silent brainstorming step. When teams brainstorm activities out loud from the start, the first suggestion anchors the conversation and subsequent contributions become edits to that initial frame rather than independent ideas. Silent writing for 5-7 minutes before any discussion produces a wider and more accurate set of candidate activities. The resulting backbone is stronger because it reflects multiple mental models rather than one person's view.
Revisit the backbone quarterly or at major product pivots, but do not change it week to week. The backbone's value comes from its stability. Teams need a fixed reference point to coordinate across sprints. If the backbone changes every sprint, it stops being a map and becomes just another artifact that needs constant maintenance.
Reserve backbone changes for genuine discoveries: a major workflow you missed, a user segment whose journey is fundamentally different, or a strategic pivot that changes the product's scope.
Use physical materials (sticky notes, markers) for the initial backbone creation, even if you plan to digitize later. Physical manipulation of cards is faster and more intuitive than dragging digital objects, and the large-format visibility of a wall makes it easier for groups to see the full journey at once. Digital tools are better for long-term storage and remote collaboration, but the initial generative session benefits from tactile interaction.
Invite 3-6 people from different functions to build the backbone together. Product, design, engineering, and customer-facing roles each carry different mental models of the user journey. A backbone built by product alone will over-emphasize features. A backbone built by engineering alone will mirror the technical architecture.
The cross-functional version is messier to create but far more accurate and durable.
Common Mistakes
Organizing activities by product feature or module instead of user behavior
Correction
This happens when the team unconsciously maps their product's information architecture rather than the user's journey. The telltale sign is activity labels that match your navigation menu: "Dashboard," "Settings," "Reports." Users do not think in terms of your nav structure. They think in terms of goals and actions: "Track my progress," "Configure my preferences," "Evaluate results." If your backbone reads like a site map, step back and re-ask: "What is the user trying to accomplish, and what do they do in what order to get there?" Rebuild from the user's narrative, not your product's structure.
Creating too many activities (10+) by mixing activities with tasks
Correction
This is the most common mistake in backbone creation. It happens because the line between an activity and a task feels blurry. " If yes, it is an activity. If it is a single discrete action, it is a task that belongs one level down.
"Search for a flight" is an activity (it contains entering dates, selecting airports, applying filters, browsing results). "Enter departure date" is a task within that activity. When your backbone exceeds 8 items, go through each card and ask this question. Demote tasks to the row below their parent activity.
Starting the backbone at the first screen of your product
Correction
Teams frequently begin the backbone with "Sign up" or "Open the app" because that is where their product's experience begins. But the user's journey starts earlier, with a trigger or need. A user shopping for a car starts with "Realize I need a new car" and "Research options," both of which may happen before they ever visit your site. Starting too late on the backbone hides opportunities to capture users earlier in their journey and causes the team to miss important context about user intent.
" That is often where the backbone should begin.
Building the backbone alone as a product manager and presenting it to the team
Correction
A backbone created by one person, no matter how experienced, reflects a single mental model. " The backbone is a shared artifact. Its authority comes from the fact that the team built it together and agreed on it. Present a pre-built backbone and the team will nod politely but never truly internalize it.
Facilitate the creation collaboratively, even if it takes longer. The alignment you build during the session is as valuable as the artifact itself.
Making the backbone too abstract with vague activity labels
Correction
Labels like "Get started," "Do the thing," or "Manage stuff" are too vague to be useful. They do not help the team understand what the user is actually doing, and they make it impossible to decompose the activity into meaningful tasks in the next step. Each activity label should be specific enough that two people on the team would independently come up with similar tasks beneath it. "Configure notification preferences" is specific.
"Set things up" is not. " If the answer is no, sharpen it.
Treating the backbone as final and never validating it against real user data
Correction
The backbone is a hypothesis. Without validation, it is just the team's best guess about the user journey, and teams are reliably wrong about certain steps. Common errors include assuming an ordering that does not match actual behavior, missing an activity that users consider essential, and including an activity that users rarely perform. Even a lightweight validation pass, watching 3 session recordings, reviewing 10 support tickets, or asking a customer success manager to walk through the backbone, will catch the most consequential errors.
Schedule this validation before you invest time decomposing activities into tasks.
Other Skills in This Method
Refining and Evolving Story Maps Across Sprints
How to keep a story map as a living artifact by updating it during backlog refinement, sprint planning, and as new discoveries emerge.
Mapping User Personas to Journey Narratives
How to anchor the story map around specific user personas and their end-to-end journey narratives to ensure the map reflects real user goals.
Facilitating Collaborative Story Mapping Workshops
How to plan and run an effective story mapping session with cross-functional stakeholders, including timeboxing, materials, and facilitation techniques.
Prioritizing Stories and Slicing Release Increments
How to draw horizontal swim lanes across the story map to define MVP and subsequent release slices based on user value and priority.
Creating and Using Story Mapping Templates
How to set up reusable story map templates in physical or digital formats using tools like Miro, Mural, or spreadsheets.
Decomposing Activities into User Tasks and Stories
How to break down high-level user activities into specific tasks and user stories that populate the vertical body of the map.
Frequently Asked Questions
How many activities should the backbone of a story map have?
Aim for 4-8 activities. Fewer than 4 means your activities are too abstract and will not provide meaningful structure when you decompose them into tasks. More than 8 usually means you are mixing task-level items in with activities. The sweet spot for most products is 5-7 activities. If you consistently exceed 8, check whether you are mapping a journey that should be split into two separate story maps, each with its own backbone and user goal.
How do I tell the difference between an activity and a task?
An activity is a high-level chunk of user behavior that contains multiple distinct steps. A task is a single, discrete action within an activity. The test: if you can imagine the user spending an entire session or a significant block of time on it, it is an activity. If the user would complete it in under a minute, it is a task. "Search for flights" is an activity. "Enter departure city" is a task within that activity. " If yes, it belongs on the backbone as an activity.
Should I build the backbone before or after creating user personas?
Build personas first, or at minimum, define your target user and their goal before touching the backbone. The backbone represents one user's journey toward one goal. Without clarity on who that user is, you will accidentally blend multiple personas' journeys into a single backbone, creating confusion during decomposition. If you have multiple personas with fundamentally different journeys, build a separate backbone for each. The [mapping user personas to journey narratives](/skills/mapping-user-personas-to-journeys) skill covers this in detail.
What if our user journey is not linear and activities happen in different orders?
Most user journeys are not strictly linear, and that is fine. Map the most common sequence, the happy path that the majority of users follow. Then annotate activities that frequently occur out of order or loop back. For example, a user might return to "Search" after "Compare options" if nothing meets their criteria. Place "Search" where it first occurs and add a visual annotation showing the loop. The backbone does not need to capture every possible path. It needs to capture the primary narrative clearly enough that the team can locate any story or task within it.
How long should a backbone creation session take?
For a small team (3-5 people) mapping a straightforward journey, 30-45 minutes is usually sufficient. For a larger cross-functional group (6-12 people) mapping a complex journey, budget 60-90 minutes. The silent brainstorming takes 5-7 minutes, clustering and merging takes 15-20 minutes, ordering and trimming takes 10-15 minutes, and validation takes 10-20 minutes. Do not rush the validation step. It is tempting to skip it when time runs short, but an unvalidated backbone will cost you more time later when you discover ordering errors or missing activities during decomposition.
Can I reuse the same backbone across multiple releases or sprints?
Yes, and you should. The backbone is designed to be stable across releases. What changes between releases is which tasks and stories beneath the backbone are included, not the backbone itself. This is the core insight of how to do story mapping iteratively: the backbone stays fixed while you [slice different release increments](/skills/prioritizing-and-slicing-releases) horizontally beneath it. Only change the backbone when you discover a genuinely missing activity, when the product scope fundamentally shifts, or when user research reveals that the journey is structured differently than you assumed.
Why does my backbone keep changing every sprint?
A backbone that changes frequently is a symptom of one of three problems. First, the activities may be at the wrong altitude, too granular, so they feel unstable because they are really tasks that should sit one level below. Second, the team may not have validated the backbone against real user behavior, so each sprint surfaces new information that reshapes it. Third, the product scope may be genuinely unclear, in which case the instability is a strategic problem, not a mapping problem. Address the root cause: raise the altitude of your activities, validate against user data, or align on product scope before mapping.