1. The history of Story Map

Jeff Patton is credited as the inventor of story mapping, and he literally wrote the book User Story Map. This idea emerged from the realization that written documents are often misunderstood or misinterpreted, while direct conversations are more effective in helping Scrum teams clearly understand user/customer needs - ultimately delivering a product that truly meets those expectations. Story mapping aims to uncover the details of what is required to deliver customer value and avoid backlog grooming sessions that don’t fully engage the audience, and consider each item out of context.

While Jeff started introducing the concept to the world as far back as 2005, it wasn’t officially termed “Story Map” until 2008. However, in the decade since its introduction, it has been adopted by many agile practitioners and incorporated into multiple tools and software solutions for product development teams.

2. What is a Story Map?

A Story Map is a method for organizing user stories to create a more holistic and visual view of a product’s features. It serves as a high-level planning tool that stakeholders can use to identify and prioritize project items early in the planning phase, based on available information. Story mapping is usually done on a wall (or floor) using sticky notes or index cards and many tapes. At its core, a Story Map is a matrix that organizes and prioritizes features and user stories of the product being developed.

What is Story Map?

3. Why use a Story Map?

User stories are effective in building a user-centric Product Backlog that describes software requirements in a realistic context. However, a user story does not reveal the complete picture; it only hints at the journey the user/customer experiences - from downloading the application to reaching their final goal.

A user story map helps us organize user stories into a manageable and structured model, aiding teams in understanding, planning, and prioritizing system functionality. The visual layout allows teams to spot functional gaps or backlog items needing attention. It facilitates comprehensive planning to maximize user/customer value.

Here are some key benefits of using this tool:

• Story Map provides a complete “big picture” view of the project backlog.
• Story Map is also an excellent tool to support smooth decision-making and prioritize the Product Backlog.
• Story Map visualizes what we already have and what is still missing to make the software/product function properly.
• Story Map is a great method to define the Minimum Viable Product (MVP). It helps prevent us from "forgetting" essential components of the software/product.
• Story Map encourages team brainstorming to generate valuable user stories.
• Story Map supports task prioritization effectively.
• Story Map enables effective user story management, keeping the team aligned toward a shared goal.
• Story Map serves as a compelling visual alternative to traditional project planning.
• Story Map is a useful model to support discussions on product quality and scope management.
• The most common usage of story mapping utilizes it as an alternative to ‘flat’ backlog management, where each item is viewed in a vacuum instead of in a visual, big-picture context. Grooming a backlog with no context might work, but you miss out on the chance to view each item’s connection and importance to the overall journey.

4. Who should be involved in Story Map?

Since a story map delivers a comprehensive product overview, participation from cross-functional teams is crucial:

• Engineering
• UX/Design
• Product Management
• Sales
• Marketing
• Customer Support
• Operations / IT
• Finance
• ... and others involved in delivering a complete product.

5. How does a User Story Mapping work?

The first step is to choose the medium for building your story map. It can be done with simple physical resources, such as a wall or whiteboard and sticky notes, or with digital tools.

Regardless of the medium, Scrum teams seeking to implement user story mapping should follow the steps below:

• To create a story map, we start by listing groups of features (or sometimes a usage sequence) for the product horizontally across the top of a matrix, from left to right. Down the columns, we arrange the user story cards in each feature in descending order of priority.
• At this point, we don't know yet how many iterations will be required to build each feature, or how the releases will be timed.
• On the top row of the story map, we place the stories that describe the essential functions needed for the system to work. This line is called the Backbone.
• On the next row, we place the stories that describe the smallest version of the system that will meet the customer's most basic needs. This line is called the Walking Skeleton. Unlike the items in the backbone, which are simply required, the items in the walking skeleton will depend on what the customer considers to be a minimal viable product.
• Finally, we place all the other user stories below the walking skeleton, in descending order of priority to the customer. So now we have a high-level picture of the product, by feature, in order of business value. 

6. What are some challenges of user story mapping?

While Story Maps are helpful for teams aiming to build fast and deliver real customer value, they may be ineffective without proper preparation. Common pitfalls include:

• Unclear target user: If you do not know who the customer is, then it is impossible to work out how they experience the product. You must know for whom you are mapping stories.
• Undefined problems: If you do not know what problem your product is solving for customers, the entire exercise of user story mapping can backfire. Building out stories towards the wrong customer goal can result in a waste of time and resources, not just in the exercise itself, but also for the sprints and releases that are based on it.
• Limited utility: Physical story maps made from sticky notes on a whiteboard are difficult to keep updated. The notes stop being sticky and fall off, whiteboards get cleaned, and the work is lost, or iterations and releases get shipped without updates to the board. Additionally, story maps built in a single, physical location do not serve teams in other locations who cannot see them. However, this can be overcome by using digital tools to build and maintain story maps.
• Re-work and redundancy: Stories from a user story map typically need to be recreated in a flat backlog afterwards - just a list. As a result, this exercise can make these folks feel that they are doing the same work twice.

7. Summary

Story Mapping is a powerful tool that achieves what traditional planning methods often cannot. It offers a high-level product vision without needing to explain every detail. It fosters a collaborative environment that engages everyone to participate in product strategy. 

However, implementing Story Mapping takes time. Project managers must advocate for its use - especially to higher-level stakeholders - by demonstrating its superiority over traditional methods. Most importantly, they must ensure that the story map is implemented effectively to deliver the greatest possible value for the product and the customer. 

Content compiled by Atoha Trainer Nguyễn Hải Hà (PMP, PgMP, PfMP, PMI-PBA,PMI-ATP Instructor)

References: PMI-ACP Exam Prep, Head First Agile, ProductPlan.com, aha.io

See more

Alternative Dispute Resolution (ADR), Negotiation, Mediation, Arbitration, Litigation

PMP Guide