The Power of Story Mapping

As I have written about frequently, to truly provide a positive experience for our end users we must have a solid understanding of the jobs they need to perform on a day to day basis. There are many tools at our disposal to sort this out, and one of those is a process called Story Mapping.

Story mapping does what it says on the tin: you map out a story comprised of tasks to identify the right things to build. As always, you must have a clear understanding of the problem you’re trying to solve, or the service you’re trying to provide, and who the users are that will benefit from your solutions as part of their job.

A story map enables us to leave the walls of software for the real-world environment of a real user. A story map can help describe the landscape in which our users use our software. A story map may often be made up of activities or tasks that can’t be in software. Having the entire context of the user’s job displayed in this format helps us find innovative solutions that we may not have initially recognized.

A good story map should read like, well, a story: “As a barista, to make a latte, first I need to steam some milk, pull a shot of espresso, then finally pour into a mug. In order to pull my shot of espresso, I must dose out the beans, grind them, and compress them into my portafilter…” You see there we identified who the persona is, their key activities (steaming milk and pulling a shot of espresso, pouring into a mug), and then we listed what tasks were required to actually get the shot of espresso (dosing, grinding, etc.).

The structure to the map is very important. Here is one example:

Notice the story is labelled by our target user. You then see that there is a primary activity (Finish a call), and then a list of tasks that it takes to do that activity (in yellow). Sometimes a task will have its own subtasks that need to be completed in order for the task to be completed. No worries! the format allows for that. The key thing to recognize is that each task flows up into the activity, “I need to do this ‘thing’, and to do that ‘thing’, I have to do ‘this’ and ‘that’.” Finally, below the tasks, you see, in gray, what it takes to do the task. These are your user stories. So now when you start planning out your work, you can verify against the map that the stories you are working against will in fact meet the user’s needs.

Perhaps the biggest benefit story mapping provides is a shared understanding across the team. The best story maps are written by key representatives from all parts of the scrum team. In some cases it’s appropriate to include actual users or individuals with experience in a relevant field. When a group of minds come together and work out the activities, it’s easy to identify gaps in the process, or gaps in the features, or where the feature might not be meeting the need entirely, and then fill in that gap. From there the team or product own can easily break out the tasks and things to be built into release swim lanes.

This visual representation allows anyone on the team, at any time, to refer to the release schedule and understand where a story sits in context to the whole. And, if at any point the team is unsure if something should be done this release, next release, or whatever, it can be easily answered by running back through the map and telling the story. If you can’t tell a complete story based on the chosen activities, the team can adjust so the user can accomplish the part of the activity they need to.