Story mapping is an collaborative method for product discovery invented by Jeff Patton. It´s based on the idea that linear backlogs are not ideal because they miss the dimension of the user flow. In this article I will share some insights from the last story mapping sessions I facilitated.
Story mapping in a nutshell
Since there are already dozens of articles about story mapping out there I will skip a detailed introduction. The idea of story mapping is to visualize the product as a map with two dimensions. The x-axis represents the flow of user tasks through the application. The process of creating a story map is a collaborative one: at first the participants write user tasks on post its and put them on a wall. Afterwards the cards are ordered in a chronological order. This forms the “backbone” of the map. User tasks can now be grouped by their topic - the activity. Every user task can be implemented with several user stories - those cards are put below the tasks they belong to.
Now comes the interesting part: as a group you now decide which stories forms the first minimal slice throughout the whole user flow, the minimal viable product. This step is important and brings out the real strength of a story map. Suppose you worked on a map which represents the “from bed to work” story, so every task you do from waking up until you reached the door of your office. The first slice could be i.e. archieved with the question “What activities are important if you only have 3 minutes to go?”
I now would like to share some hands-on experience I made during facilitating my last mapping sessions.
It´s not always the happy path
In my experience we focus quite often on finding the happy path throughout the application to build. In our case we found out during the conversations that it would be more valuable to start with the error cases. Sounds like a trivial insight, but having real customer value right from the beginning is an essential part of agile software developement and the mechanics of user story mapping helped us with that.
Use named slices instead of version numbers
Seeing the real need of the customer was supported by the way we give the releases a name. Instead of “0.1” we thought about “Automatic error detection & display”. By giving the release a name we had an anchor for customer value.
Make a dry run before mapping the actual product
This time the mapping session went really well because we were able to focus the flow of user activities without technical details. Personally I think this is crucial in the understanding and using user story maps. Too often I faced the issue during moderation that technical issues blurred into discussion which had no value by it´s own. If you realize that your colleagues have no experience with such mapping formats, make a dry run and use some simple example from your daily routine (i.e. from bed to office) and try to mapping that.
Repeat and include
Having a great story map but not working with it by including it in your development process is wasted effort. Too often I have seen that the spirit of a mapping session was lost just because it was treated as a “Kick-off” thing and the backlog was structured as usual. Include the story map in your product refinement process and have regular smaller session where you work on the map.
Make moderation explicitly
From my experience it´s easy to fall of the track and i.e. get lost in technical discussions. So it´s good to have a dedicated moderator on board, ideally with some experience with the idea of story mapping.
You would like to try more holistic product management methods and need some help? I can support you!