When you have answers to your questions, make sense of what you've learned.

Story mapping


A visualization of the work needed to build or improve a product, organized from the perspective of a person using the product — essentially a two-dimensional view of the product backlog.


To provide stakeholders with an overview of the proposed product functionality in a way that more clearly illustrates the value provided by the product and the way a person experiences it than is possible with the typical, flat backlog.


Time required

2–4 hours (per session)

How to do it

  1. Gather the team.
    • Because this is a work planning activity, it should involve the whole product team, including the product owner and any available SMEs or representative users as well.
  2. Review the brief.
    • Start by setting context for the team by reviewing the product brief, including the vision, scope, and context for the product and current initiative.
    • If available, review any research findings that may have been gathered, including who the team is designing for and what we know about their goals and pain points.
    • If user research is not available, capture initial assumptions, but identify them as such and include discovery work in the story map.
  3. Build the backbone.
    • The backbone outlines the high-level functionality of the product, in the language of the value it provides for the user and roughly in the order the user might experience it in. It should look similiar to the stages of a journey map. (See the resources below for some examples of how this looks.)
  4. Capture work.
    • Set a time box for participants to individually capture work they think needs to be done to support the backbone.
    • This can be done in the form of user stories, and they can be grouped into epics as needed.
    • Participants should focus on the areas of work they are most familiar with, so developers are adding items for development work and designers are adding items for design work, for example.
  5. Share and refine.
    • After participants have had a chance to enter items, talk through each segment of the backbone until the team feels they have captured everything needed based on what they know at the time.
  6. Define release points.
    • Once the story map is filled out to the team’s satisfaction, define breakpoints that represent releases.
    • The story map format ensures each release enables some version of the full experience intended for the product.
  7. Run additional sessions as needed.
    • The entire story map doesn’t need to be completed in one session. It may make sense to break up the context setting and work capturing.
    • If using Miro and Jira, it’s possible to connect them to maintain a view of the backlog in both locations.

Additional resources

Considerations for use in government

No PRA implications. The PRA explicitly exempts direct observation and non-standardized conversation, 5 CFR 1320.3(h)3. See the methods for Recruiting and Privacy for more tips on taking input from the public.