Story Mapping was conceived by Jeff Patton and written a book about it. In my role as a UX Consultant running UX workshops, at clients’ organizations or in our in-house software team, I do a lot of Story Mapping. It is instrumental in getting a product right. For me, a UX professional coming from the 90s, requirements management used to be a dedicated role with a lot of limelight within the project teams. However, as the teams moved to an Agile development environment, requirements manager is a shared role.

At least the new Requirements Manager, if one exists, is more a tools manager than the one who used to create a pile load of documents while being in the hot seat. Agile deals with project uncertainty by lowering risk for each iteration of development whereas; having to write all the requirements documents at the beginning of the project was equivalent of a big-bang approach. In some extreme cases, requirements managers were rewriting requirements to match the product that was shipped.

Story mapping directly deals with stakeholders telling stories, and building a common understanding about those stories via active brainstorming. Building of the product happens via mapping most basic of those stories first and then incrementally repeated, ensuring user validation and course correction happens at every step.

The objective of story mapping is to create a product that provides the desired positive impact. It is completely fine even if there is a relatively small impact in the initial iteration or the skeletal product. The key point is to get it right, right from the beginning. Highly relevant for Startups, a Minimum Viable Product (MVP) can be most effectively created via applying Storymapping doing a little something of everything that constitutes a working product. Attempting to create that polished and shiny product in the first attempt often is a recipe for failed products.

“Focus on the breadth of the story before diving into the depth.” — Jeff Patton

In fact, the initial iterations of the product could just be with Prototypes that may look and feel like real product while having the agility to rebuild with little effort. Extensive user validation of the initial product versions must be done so that the product definition is what the users need.

The results of learning from users (via User Research) must be reapplied to the original story so that it gets refined. That is the core purpose of Agile — learning. The way it’s written in the book “Plan to Learn, and Learn to Plan”.

Something that often goes wrong in project teams is the change of people involved in the course of the project. For a product, it is super essential that people who were involved in creating the story stay in the team. This is simply because they are the ones who have a good understanding of the story and rationale behind each aspect of the story.

To summarise, here are the benefits of Storymapping:

· Helps the whole team develop a common understanding of the requirements

· Ease of course correction based on user evaluations of under development Product

· Focus more on impact of the product in question to the Users than just the project output

· Helps in the planning of Sprinting session and releases, based on priority

· Prudent spending of Project budget

Story Mapping and Story Telling are not the same

Story Telling is a method of sharing individual user’s story. It is a method used in all UX teams, in the form of Personas and Scenarios whereas, Story Mapping is more of a bird eye view of the entire Users’ stories and how each piece of User’s story is related to the bigger story.

More info:

Jeff Pattson’s article on the idea on Story Mapping (without giving it the name) in 2005

Interviews with several experts on the topic of Story Mapping