Story Mapping

Story Mapping

Plan release cycles by organizing user stories into a step-by-step segmented flow


Framing Inception

Suggested Time

1 hour


Core team, stakeholders

Why do it?

We use story mapping to collaboratively translate the users’ journey into tasks, broken down into epics and user stories as we transition from Discovery & Framing to delivery. This helps us to sequence user tasks, create a prioritized product backlog and chunk initial product releases. A story map also creates shared understanding about the functionality of the product.

When to do it?

During inception, to translate Discovery & Framing outcomes (likely a product prototype and user journeys) into a prioritized product backlog.

What supplies are needed?

  • Whiteboard or digital version like Miro
  • Sticky notes
  • Markers
  • Blue painter’s tape

How to Use this Method

Sample Agenda & Prompts

  1. Before mapping, create a short product or feature brief to frame and constrain what you map. Think of this as the big story. What is the product you are creating or the problem you are solving? Who are the customers or users? How does each user benefit? Why are you interested in building this and how do you benefit?

  2. Hand out a stack of stickies (of the same color) to each of the participants. Explain that everyone is going to use these stickies to tell the story of the product through user tasks.

    Tip: The story should start with the first action your “primary user” takes. As the story unfolds, other users may need to be weaved into the story. That’s fine! (Sometimes, from a narrative perspective, it makes sense to weave in the computer or device as a user too!) Just make sure participants note which users are taking the action on a given sticky.

  3. Give everyone a few minutes to silently generate user tasks that together compose the narrative flow of the product or solution.

    Tip: At this point, it’s important to remain a mile wide and inch deep. Getting the full scope of the story is more important at this point than getting all the granular detail.

  4. Start putting user tasks on the whiteboard by asking each participant for a task, one at a time. If there are duplicates, use the one that best captures the step and discard the rest.

    Tip: Focus on a single happy path for this step. We will incorporate secondary actions later.

    Check with the group after adding each task to make sure the order feel rights and critical tasks have not been skipped.

  5. Optional: Use stickies to label groups of user stories by their corresponding epic.

  6. Have the participants to come up to the whiteboard and engage with the map. Ask them to think about variations or deviations from the “happy path” already outlined.

    Tip: Play “wouldn’t it be cool if?” and feel free to go as blue sky as you’d like. Add in product details, like proposed UI or business rules.

  7. Ask the participants to write these secondary tasks on stickies and place them underneath the backbone stickies in the appropriate order.

  8. Decide how many releases you’d like to divide the map into (you can always adjust this later).

  9. Use the tape to slice the story map into segments (releases) of user stories that will provide relatively equal value.

  10. Define the goal of each release and write it next to each corresponding release.

  11. Reassess the placement of each user story. Move stories if necessary.

Success/Expected Outcomes

You’re done when the team feels like they have an accurate representation of what will be built and a backlog of users stories.

Facilitator Notes & Tips

A user task is a short verb phrase like “read an email” or “respond to a message”. Don’t get too detailed. Stick to tasks at the functional level. This means the resolution of the task is right when it’s as big as it can be without a person plausibly taking a break in the middle of it. (e.g. In the story of my daily routine, a task might be “taking a shower”. “Changing the temperature” of the shower is too detailed (sub-functional) while “Getting ready for work” is too broad.

Work on the happy path first. Then in the deep dive portion, capture the alternative paths a user might take through the product.