Or “What is User Story Mapping”
Or “How Do We Break Down a Big Chunk of Work”

A lot of people, while they like the simplicity of the approach of maintaining a backlog, feel like they lose context when they just have a list of user stories. Others cannot think in terms of lists but rather need something more pictorial to help them understand what is going on. One approach that I have seen useful in these contexts is the use of “User Story Mapping”.

The basic idea, made popular by Jeff Patton is pretty straight-forward. It is a top-down exercise to understand the workflow. The idea is to start with the activities a user / role needs to do to accomplish an objective / goal. Then detail out stories that represent the effort done by each user. Next, prioritize them into sprints (or whatever time horizon you are working toward). The activities can be based on larger features or epics coming into a planning session or perhaps are just something that needs to be elaborated.

What you end up with is a matrix with activities / stories on the horizontal axis (user does this, then does that, then does that) and priority in the vertical axis (this is the most important function to provide, this is the second, etc. Swim lanes identify potential delivery timescales. In other words, a visual workflow and plan combined in one. Here is an example for an email client experience:

Email Example

In this picture you can see blue user activities, the with stories required to support that activity in yellow underneath. You can see they have said “this is what will happen in the first increment” by creating swim lanes. These time horizons can be whatever makes sense in your situation. Perhaps a sprint by sprint view, perhaps a “Program Increment” view if working in a SAFe environment.

A couple of notes:

• This is clearly a way to start the identification of a solution. As you discover more, the basic picture can be expected to change. If you already have business process documentation in place, feel free to leverage this (it is a “waste” not to leverage the intellect of the organization.)
• Another approach to story map is to take a bottom up approach – do a brainstorm of business activities, group into processes then map to the feature’s acceptance criteria. The approach you take will depend on your current level of knowledge.
• You can use this picture help others understand where you are and to maintain context. For example, you could mark on each story “done” as things are complete, and as you get feedback update / add items to the story map that you already have.

By way of understanding, the benefits of this approach, especially if it is done as a collaborative exercise, include:

• It helps the team to visualize all the tasks that make up something valuable to a customers, pinpointing dependencies
• It encourages iterative development by slicing activities into smaller efforts, and is particularly good at helping to write and present these as a user's view (i.e. user stories)
• It helps to identify areas that have been missed, filling in details as we learn more.
• It helps teams to maintain context.
• It allow people to maintain a big picture of what we are trying to do, tracking the progress made which improves accountability
• It helps the team gain more insights into the user’s journey and experience with using the solution in its overall context, increasing end user domain knowledge
• It helps the Product Owner think about and convey better the value a solution offers to the team and other stakeholders

• Video by Jeff Patton
• A very basic blog post on the approach
• "User Story Mapping" - Jeff Patton. The canonical book on the overall approach.
• How Do We Split a User Story
• Collection of Reference from Story Mapping software vendor Stories On Board
• And, of course, Dilbert on User Stories – gotta have Dilbert:-)