Story Mapping 101

By August 9, 2017Agile Tools, Article

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 with each other.

Picture of a product backlog

Backlogs vs. Story Maps

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.

Story Maps were invented by Jeff Patton [his book can be found here] to help discover requirements from a user experience point of view. The process of creating a Story Map is a collaborative exercise with stakeholders. This helps transform our approach from requirements delivery to requirements discovery.

How To Approach Creating The Initial Story Map

There are two approaches I like to use when building the map:

Tell a story: Ask one of the Subject Matter Experts (SME) to walk through the problem by telling a story of the activities and tasks they would perform. As they are telling the story have multiple people (Dev team?) armed with post-it notes and sharpies. As they hear a task the user needs to perform someone writes it down and places it on the wall. We place them roughly in time order from left to right, but not everything is perfectly linear and that is ok. Below is an example of a story map for an ecommerce site.

Everyone writes: This usually works when you have multiple SME. Everyone writes the tasks they would need to do and then they combine into 1 map by removing duplicates.

Creating The Story Map

Once you have all of the activities and tasks, it is time to order:

Group into activities: Once the initial story map is built we then want to identify groupings and define those as activities. I find that if I am saying I could do X or Y or Z then those will be organized in a column as a set of options. Or if I have a bunch of related items I would do together. If I would do A then B then C as different discrete things then these are probably being placed horizontally.

Tasks grouped into activities for story map

Test for gaps: Next, I will look for missing tasks for my map. I will do this by having someone walk through another scenario or from a different perspective (I.e. Different user persona). While that person is walking through this other scenario I will have another person stand at the board pointing at the story map when they see items that are already covered. If they hear something that is missing then the rest of the team is armed at the ready to capture the new task on another post-it. This will allow us to flesh out any missing pieces.

test for gaps image in story map

Prioritize: Now as a team we review the story map and prioritize. Within activities/columns, we move items up that are most important and items lower that are not as important. We can order within an activity and we can also create different swim lanes across the story map for different levels of priority (ex: Must, Should, Could).

Define Iterations: Now that we have the map prioritized we can outline iterations or releases of our map. We can draw a line for Release 1. From there we can estimate the work with the team and maybe refine our scope.

Define iterations using a story map or story mapping technique

Keep it Updated: Imagine showing up to the first Sprint Review and bringing in the map (I had a team do this on a rolling whiteboard) and communicating progress by showing an updated map with items marked complete. Wouldn’t the stakeholders who were involved with the map have a better understanding of progress, rather than telling them you have finished 20 of 100 points on the backlog? Story maps are not only powerful for capturing requirements but also continual visibility.

Stay tuned for the second Story Mapping post, where Reese will discuss how to transform an inherited backlog into a story map. 

 

Join the discussion 3 Comments

  • Ned Horvath says:

    Nice! Looking forward to part 2.

  • Kim says:

    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.

  • Amalia Litsa says:

    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.

Leave a Reply