Blog

Story Mapping 101

By David Hawks | Aug 09, 2017 |  Agile,  Agile Marketing,  Agile Technical Practices,  Agile Tools,  Agile Training,  Kanban,  Process,  Product Owner,  Scrum,  ScrumMaster,  Team

Traditional product backlogs can get confusing. They typically start off with a high-level list of features, called “epics”. However, as the team starts decomposing the epics during refinement down to sprintable user stories, it’s easy to “lose the plot” and the only person with the decoder ring is the Product Owner (PO). The PO is the only one who knows how all the stories tie back up to the feature and how they relate to each other. One resulting failure pattern is incremental deliveries that create poor user experiences. This is because the release was composed of stories that in principle were of high business value but were functionally dependent on stories that were of lower value and were therefore deferred to future releases.

Picture of a product backlog

To the Rescue: Story Maps

The challenge presented by traditional backlogs is they are flat and do not convey any notion of the end user’s journey (See the “Outside View” column in the graphic above.) This makes it difficult to recognize if any gaps exist. Also, we can easily lose business context when trying to prioritize many user stories against each other.

Story Maps were invented by Jeff Patton [his book can be found here] to help overcome those challenges. Patton’s process helps teams discover requirements from a user experience point of view. Creating a Story Map is a collaborative exercise that incorporates the needs of the end users, the stakeholders, and the wisdom of the team, the makers. This helps transform the approach from product requirements delivery to user requirements discovery.

How To Approach Creating The Initial Story Map

There are a couple of different approaches we use when building user story maps:

1) Tell a story: Ask one of the stakeholders, or a representative such as a Subject Matter Expert (SME) to walk through from start to finish all the activities and tasks the end user would perform (the problem the team wants to solve) by telling a story. As they are describing the customer journey, multiple people (e.g., the Dev team) armed with post-it notes (digital or IRL) write down each task and place it on the wall (again, virtual or IRL). The tasks are placed roughly in time order from left to right, but not everything needs to be perfectly linear. Below is an example for an e-commerce site. (BTW, both Mural and Miro have some nice templates for User Story Mapping).

2) Everyone writes: This approach works well when you have multiple SME’s. Everyone independently writes out the tasks they would need to do and then collectively they combine them into a single map by removing duplicates.

[If you want to learn more about how to use Agile techniques to build better products, check out our guide to great Agile transformations, 8 Common Pitfalls of an Agile Transformation.]

Creating The Story Map

Once the team has an initial pass of the activities and tasks, they add a bit of organization to the map.

Group into activities: Once the initial story map has been constructed, the team then identifies groupings and defines those as activities. For example, if the user could do X or Y or Z, then those will be organized in a column as a set of options. Alternatively, if the user would do A then B then C as different discrete things, then these are placed horizontally.

Tasks grouped into activities for story map

Test for gaps: Next, the entire group will look for missing tasks on the map. They can do this by having someone walk through another scenario or from a different perspective (e.g. A different end user persona). While that person is walking through this other scenario another person follows along pointing at the story map to confirm things are already covered. If they hear something that is missing then they or other members of the team capture the new task via a  post-it. This allows the team to flesh out any missing pieces.

Test for gaps in your story map image

Prioritize: Next the team reviews the story map and prioritizes the tasks. Within activities/columns, they move items up that are most important and items lower that are not as important. They can order within an activity and can also create different swim lanes across the story map for different levels of priority (e.g. Must, Should, Could).

Prioritize story map into must, could, and should

Define Iterations: Now that the team has the map prioritized they can outline iterations or releases of the story map. They can draw a line for Release 1. From there they can estimate the work and refine the scope of the release as needed.

Define iterations using a story map or story mapping technique

Keeping the User Story Map Alive: Story maps are not only powerful for capturing requirements for a full user journey, but also for continual visibility. Imagine showing up to the first Sprint Review and bringing in the user story map with items marked as complete to communicate progress. Wouldn’t the stakeholders who were involved in the initial map have a better understanding of progress, rather than telling them you have finished 20 of 100 points on the backlog? 

Take a Deeper Dive into User Story Mapping

We cover user story mapping in-depth during our Certified Scrum Product Owner (CSPO) class. Check it out. The CSPO class is offered as a public workshop or in a private setting.

Also, read the next installment of this series, Story Mapping 201, where we discuss how to transform an inherited backlog of user stories into a story map to avoid half-baked incremental releases. 

The Origins of User Story Mapping

Books / Podcasts

12 Responses to “Story Mapping 101”

  1. Love these diagrams. Story Mapping is truly an art and not a science. This gives a really nice way for someone, (like me) who’s new to the PO role, to take the important first steps of having a conversation to start the storytelling process.

  2. Amalia Litsa

    I think the Story Map is a good idea for helping the team relate their tickets to the final experience. However, the act of building a story map should not replace actual testing and iteration. If real users are not testing your design, the team is committing time and money to guess-work.

    Here is my idea of how to do the above, but with design:

    Team designs the hero flow on a whiteboard, agreeing upon the sequence of steps the user would take to complete the task. The designer builds a prototype of this hero flow. While doing so, the designer will pick up and mend little-gotchas the group had not thought of. Designer conducts a usability test of this hero flow with actual users (you can use a service like usertesting.com to greatly expedite this step). Designer summarizes the main design flaws to the team, and together they brainstorm solutions. Designer tweaks the prototype accordingly and re-submits the test. The team iterates this way until the design is satisfactory (the PM can make this call).

    Now that the team feels confident in the design, the engineers can split the design into stories, estimate cost, and arrange them into a story map as described above. The PM can prioritize.

    The designer will need a little time to think through edge-cases and interaction design. For example, how long should this page load before timing out? What do success and errors look like? If the team does not have a pattern library of design standards to reference, the designer will want to work with the engineers to answer these questions. Anyway, this additional design-time is something to consider in sprint planning.

    If you do not have a designer, you can still rapidly test and iterate before building product-level code. Just have one of the developers code up client-side vaporware with dummy data. Don’t spend time on Javascript; the only interactions that need to work are the links or buttons that take you from one screen to the next. The PM, then, can orchestrate the usability test.

  3. This is great, and I have used Story Mapping with many Software applications. Does anyone have any tips on how we apply this to solving problems with analytics? How we can apply Story mapping in Big data world?

  4. […] Teaser: Backlogs can be confusing. They typically start off with a high-level list of features, which we call “epics” that make sense to everyone involved. However, as we start decomposing all the way down to sprintable stories soon everyone will be lost and the only person with the decoder ring is the Product Owner. They are the only one who knows how all the sub stories tie back up and relate to each other. The challenges presented by traditional backlogs is they do not convey any notion of workflow. This makes it difficult to recognize if any gaps exist. Also, we lose business context when trying to prioritize all the smaller stories against each other. Read more… […]

  5. Story mapping a project would identify what is the flow making it easy to identify and pinpoint the possible errors if you encountered. You can easily identify the tasks of other team members and start where they left. Thank you for writing great content.

    • Resalin Rago

      Glad you found it helpful. If you need more info on story mapping, another one of our Agile coaches, Reese Schmit, did a follow-up on how to do this mid-project.

Leave a Reply

Your email address will not be published. Required fields are marked *

< Back