How to run a story mapping workshop

TL;DR

Summary

3 hours to slice a topic into small, actionable items and prioritize them as a team through visual management.

Goal

Have a full view of the topic to scope, sorted by category (activities) and prioritized into Must Have / Should Have / Nice to Have, ready to feed the product backlog directly.

Why run a story map?

A classic backlog is a vertical list of user stories. The problem: it’s impossible to picture the full user journey by reading it. You see slices, never the big picture.

That’s exactly the observation that pushed Jeff Patton to formalize the story map in his book User Story Mapping (O’Reilly, 2014). His answer: lay items out on two axes:

• The horizontal axis represents the user’s chronological journey (left to right).
• The vertical axis represents priority (top to bottom, from most to least important).

This dual axis lets the whole team see at a glance what the user does, in what order, and what’s the priority. It’s a communication tool before being a planning tool.

Definition: A story map is a visual representation of the user journey, sliced into activities (high-level steps) and tasks (detailed actions), organized chronologically and prioritized vertically.

What you need

Prep everything before participants arrive. Nothing’s worse than a workshop that starts with 10 minutes of marker hunting.

On-site:

• Sticky notes in 2 different colors: one for activities, one for tasks (1 pad per person, so about 6 to 10 pads total)
• Thick markers (1 per person): thin markers can’t be read from a distance
• A large empty wall or a cork board (at least 3 meters wide)
• Masking tape (to draw the priority lines)
• A flip chart for expectations and questions
• A camera or a phone to document the final result
• A visible clock or a projected timer

Remote (Miro / FigJam):

• A Miro or FigJam board prepared with the zones laid out
• A template with the horizontal axis and the 3 priority zones pre-drawn
• A consistent color scheme for activities and tasks (use the virtual sticky-note colors)
• A video call link with cameras on

Group composition

The workshop ideally runs with 5 to 8 people. Beyond 8, discussions get too long and prioritization turns into endless debate.

Required profiles:

• The product or project lead: this is the person who will make the call during prioritization. Their presence is essential.
• Members of the technical team: developers, designers. They bring the reality of feasibility and think through edge cases.
• One or two business representatives: they know user needs and business constraints.
• The facilitator: they facilitate, reframe, and manage time. They don’t take part in the content.

If you can’t get the product lead, postpone the workshop. Prioritization without a decision-maker is an empty exercise.

Program (3h)

Phase 1: Workshop walkthrough (15 min)

Show the video

Start by playing this short video that explains the story mapping concept:

For this workshop, the “steps” in the video will be called activities and the “user stories” will be called tasks.

Restate the goals

State the goal clearly: “By the end of these 3 hours, we’ll have a full view of the user journey, sliced into activities and tasks, and prioritized into Must Have / Should Have / Nice to Have.”

Hand out materials

Give each participant a pad of sticky notes (the “tasks” color) and a thick marker. Keep the “activities” color sticky notes for the collective exercise that follows.

Gather expectations

Run a quick round of introductions: “What do you expect from this workshop?” Note the answers on the flip chart and leave it visible during the whole session. That lets you check at the end of the workshop whether expectations were met.

Phase 2: Writing the activities (15 min)

Activities are the high-level steps of the user journey. They describe what the user does at a macro level.

How to spot an activity

An activity answers: “What is the user doing at this point in their journey?” It always starts with a verb in the infinitive and fits on a single sticky note.

Examples of good activities:

• “Discover the offer”
• “Create an account”
• “Place an order”
• “Track delivery”

Examples of poor activities (too vague or too detailed):

• “Use the site” (too vague, that’s the whole journey)
• “Click the Add to Cart button” (too detailed, that’s a task)

How it runs

Writing the activities is collective. The facilitator leads the discussion, the team proposes activities, and they’re laid out in chronological order on a first horizontal line, left to right.

Aim for between 5 and 10 activities. Below 5, your journey is probably oversimplified. Above 10, you’re probably too granular.

Example for a sports club site:

• Find a match date
• Buy my tickets
• Get my tickets
• Attend the match
• Share my experience

Phase 3: Writing the tasks (1h15)

This is the longest and richest phase of the workshop. Tasks are the detailed actions within each activity.

How to phrase a task

A task answers: “Concretely, what does the user do to complete this activity?” It also starts with a verb in the infinitive and fits on a single sticky note. Write big, in 3 to 5 words max.

Important rule: each task must describe a user action, not a technical feature. “Filter dates by month” is a good task. “Implement a filter component” is not.

How it runs

Unlike the activities, the tasks are written individually first, then collectively:

1. Individual phase (20 min): each participant silently writes the tasks they imagine, one per sticky note.
2. Collective phase (55 min): each person comes and sticks their notes under the relevant activity, briefly explaining. The team groups duplicates, debates differences, and fills gaps.

If a task doesn’t fit any existing activity, that means an activity is missing. Add it. If an activity has no tasks, it might be unnecessary. Remove it. The story map is a living document that adjusts during the workshop.

Detailed example for a sports club site:

Activity: Find a match date

• Browse the match calendar
• Filter by team
• Pick a date
• Read additional info (location, time, opponent)

Activity: Buy my tickets

• Pick my seat category
• Pick the number of tickets
• Add my picks to the cart
• View my cart
• Confirm my cart
• Enter my payment info
• See the payment confirmation

Activity: Get my tickets

• See my ticket on the site after purchase
• Find my ticket in my account
• Receive my ticket by email
• Add the match to my calendar

Phase 4: Break (15 min)

Never underestimate how important the break is. After 1h30 of intense work, the brain needs to switch off. Use it to take a photo of the current story map: if sticky notes fall during the break, you’ll be able to put them back.

Phase 5: Walkthrough and review (15 min)

After the break, the team steps back and re-reads the whole story map.

The walkthrough test

Ask one team member to “tell the story” by walking through the activities and tasks left to right, top to bottom. The others listen and react:

• Does the journey make chronological sense?
• Are there gaps (moments where the user doesn’t know what to do)?
• Are there alternative journeys missing (errors, edge cases, first-time vs. returning user)?

Alternative journeys

Think about cases like:

• The user arriving for the first time vs. the one coming back
• The user running into an error (payment declined, page not found)
• The user on mobile vs. on desktop
• The admin vs. the end user

Add the missing tasks. Don’t hesitate to create new activities if needed.

Phase 6: Prioritization (45 min)

This is the most strategic phase. It turns a visual map into an action plan.

The MoSCoW method

Prioritization uses the MoSCoW method, formalized by Dai Clegg in 1994:

• Must Have (essential): without these tasks, the product doesn’t work. It’s the bare minimum viable.
• Should Have (important): the product works without them, but the experience is degraded. It’s the V1 target.
• Nice to Have (desirable): it would be nice to have, but it’s not critical. That’s V2 and beyond.

There’s sometimes a 4th level, Won’t Have (excluded for now), but in practice the first 3 are enough.

How to draw the lines

To the left of your story map, draw 2 horizontal lines with masking tape. These lines divide the vertical space into 3 zones:

• Top zone: Must Have
• Middle zone: Should Have
• Bottom zone: Nice to Have

How prioritization runs

Work column by column (activity by activity):

1. The facilitator reads the tasks of an activity
2. The team discusses the priority of each task
3. The product lead makes the call when there’s disagreement
4. Sticky notes are moved vertically into the right zone

Heads up: prioritization is relative, not absolute. A task is “Must Have” relative to the other tasks in the same activity. The goal is to reduce the scope of the first version, not to classify everything as Must Have.

The “everything is priority” trap

If everything is Must Have, nothing is. As a rule of thumb, aim for this split:

• Must Have: 30 to 40% of tasks
• Should Have: 30 to 40% of tasks
• Nice to Have: 20 to 30% of tasks

If your Must Have zone holds more than 50% of the tasks, challenge each item: “If we don’t do it for V1, is the product unusable?” If the answer is no, demote it to Should Have.

Common mistakes

After running dozens of story maps, here are the mistakes I see most often.

Being too granular

Some teams go all the way down to form fields: “Enter your last name”, “Enter your first name”, “Enter your email”. That’s too fine. At this stage, a single task “Fill out the sign-up form” is enough. The detail comes in the user stories during development.

Being too vague

The opposite is just as problematic. “Manage your account” isn’t a task, it’s an activity. If a sticky note can be sliced into 5 sub-elements, it’s probably an activity disguised as a task.

Forgetting edge cases

Main journeys are easy to spot. It’s the error journeys, edge cases, and side journeys that are often missed. Always ask: “And what if something goes wrong at this step?”

Prioritizing too early

Some teams want to prioritize each task as they write it. Resist. Prioritization happens at the end, when the full picture is complete. Prioritizing too early biases judgment because you don’t yet have the global view.

Not involving developers

The story map isn’t an exercise reserved for the product owner and designers. Developers bring an indispensable technical view: they think about edge cases, integration constraints, technical dependencies. Their presence considerably enriches the story map’s quality.

Adapting the workshop for remote

The tools

Miro and FigJam are the two most suitable tools. Create a board with:

• A horizontal line for activities
• A wide space below for tasks
• 2 priority lines pre-drawn
• A clear color code (yellow for activities, blue for tasks, for example)

The adjustments

• Shorten the duration: 2h30 instead of 3h. Attention is shorter on video.
• Use a visible timer on the Miro board.
• Ask for cameras on: it’s essential to read reactions.
• Use dot voting for prioritization: each participant gets 10 dots to spread across the tasks they consider priorities. That speeds up the discussion considerably.
• Take more frequent breaks: a 5-minute break every 45 minutes.

The remote pitfall

The biggest risk in remote settings is silent disengagement. In person, you see who’s checking out. On video, someone can turn off their camera and do something else. To counter that, regularly call on participants by name and ask them to react.

What to do after the story map?

The story map is an intermediate deliverable, not an end in itself.

1. Photograph or export the story map (in person, take several photos from different angles)
2. Digitize the Must Have tasks in your backlog tool (Jira, Linear, Notion…)
3. Kick off prototyping: designers can create the first mockups based only on the Must Have tasks. That’s the natural link to a design sprint.
4. Display the story map in the team’s workspace (or keep the Miro board accessible) so it’s a reference throughout the project

Before / after example

Before the story map: a flat backlog of 47 user stories, no order, no priority, no overall vision. The team doesn’t know where to start. The product owner has an idea in mind but no one else shares it.

After the story map: 7 activities, 52 tasks chronologically organized, prioritized into 3 levels. The team sees the full journey. V1 is clearly identified (18 Must Have tasks). Developers know what comes first. Designers know which screens to mock up. The product owner has validated priorities in front of everyone.

The difference isn’t in the volume of information. It’s in the readability and the consensus.

Going further

• The ideation workshop: the workshop that often precedes the story map to generate ideas
• The design sprint: a 5-day framework that can include the story map
• The experience map: to map the overall user experience
• The Mission / Vision workshop: to scope the project before the story map

Sources

• Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly, 2014
• Dai Clegg, MoSCoW method, 1994 (formalized within the DSDM framework)