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.
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 e-commerce 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.
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.
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.
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.
Don’t forget to read the next installment of this series, Story Mapping 201, where Reese Schmit discusses how to transform an inherited backlog into a story map.