Hello! Welcome to the next lesson in our module on Business Analysis in an Agile Context.
In our last session, we focused on deconstructing large features, or "epics," into small, manageable user stories using frameworks like SPIDR. You now have the skill to create the essential "ingredients" for an Agile backlog. However, a simple list of user stories can feel flat and disconnected, making it hard to see the big picture or explain the product's narrative to stakeholders.
Today, we will address this challenge by learning how to apply story mapping techniques to visualize product functionality and plan releases. A story map takes your collection of user stories and arranges them into a powerful visual tool that tells the complete story of the user's journey. For a Business Analyst, this is a cornerstone technique for facilitating shared understanding, prioritizing work, and communicating a clear product strategy.
This lesson will equip you with a method not just for organizing requirements, but for strategic planning—a skill essential for both acing BA interviews and effectively managing stakeholder expectations in a new role.
1. What is a User Story Map?
At its core, a user story map is a way to organize user stories into a more useful, two-dimensional grid. It was created by Jeff Patton to help teams see the whole system from a user's perspective. Instead of a flat backlog, you get a dynamic map that shows how all the pieces fit together.
The map has two axes:
- The Horizontal Axis (The "Backbone"): This represents the user's journey through the product from left to right. It tells a story. For example:
Register Account->Search for Product->Add to Cart->Checkout. These high-level steps form the "backbone" of your map. - The Vertical Axis: This represents priority and alternatives. Under each step of the backbone, you stack the related user stories. The most essential stories go at the top, and less critical ones or alternative ways of doing things go below.
To see this structure in action, let's watch a video from Mike Cohn, a leading figure in the Agile community.
User Story Mapping Tutorial (How to create, read, and use story maps)
The video 'User Story Mapping Tutorial' by Mountain Goat Software provides a foundational explanation of how to create, read, and use a story map. It clearly breaks down the two-dimensional structure.
Please watch from 00:49 to 06:00. As you watch, focus on: How the horizontal dimension tells a story using the word 'then'. How the vertical dimension shows alternatives and priority using the word 'or'. The key vocabulary: backbone, activity (often an epic), step, and narrative.
To reinforce this structure, here is an example of what a story map looks like.
2. How to Build a Story Map: A Practical Walkthrough
Now that you understand the structure, let's walk through the process of creating a story map. This is typically a collaborative workshop activity that you, as a BA, would facilitate. You would gather stakeholders, developers, and designers to build a shared understanding of the product.
The following video provides a great case study of a BA creating a story map for a new online food delivery service.
User Story Mapping | Business Analyst Skills | EP 1
In 'User Story Mapping | Business Analyst Skills', ThePrefectBA channel demonstrates the creation of a story map from scratch. This practical example is perfect for seeing the theory in action.
Watch from 02:27 to 11:17. Pay attention to how the BA, Raj, facilitates the process: He starts by asking stakeholders for the high-level activities the customer will perform (Browse, Order, Pay, Track). This forms the backbone. He then drills down into the specific tasks (user stories) for each activity (e.g., under 'Pay', the tasks are 'Pay with cash', 'Pay with card', etc.). He explains how these activities and tasks translate directly into epics and user stories in an Agile framework.
This process gives you a complete, visual product backlog. As the video highlights, this is far more intuitive and communicative than a long list of requirements in a spreadsheet.
For a summary of the steps involved, you can refer to the following article. It provides a clear, step-by-step guide that is useful to have as a reference.
Mastering User Story Mapping in Agile Projects
The article 'Mastering User Story Mapping in Agile Projects' provides a concise, text-based guide to the creation process. This is a great resource to bookmark for future reference.
Read the section titled 'Creating a User Story Map'. Notice how the steps align with the video: gathering people, defining goals/activities (the backbone), breaking them down into tasks, mapping them, and prioritizing.
3. From Map to Roadmap: Planning Your Releases
Here is where the story map becomes a strategic planning tool. Having all the functionality laid out and prioritized vertically makes release planning incredibly straightforward. You can "slice" the map horizontally to define what goes into each product release.
The first slice is typically your Minimum Viable Product (MVP)—the smallest version of the product that you can launch to deliver core value to users and start gathering feedback.
Let's return to the Mountain Goat Software video to see a clear explanation of this "slicing" technique.
User Story Mapping Tutorial (How to create, read, and use story maps)
This clip from the 'User Story Mapping Tutorial' is crucial. It shows how to draw horizontal lines across the map to define what will be built and when.
Watch from 08:56 to 10:25. Focus on how a simple horizontal line creates a clear plan for the MVP and a subsequent release. Notice that the MVP doesn't have to include a story from every single column.
Now, let's see this applied to the food delivery service case study.
User Story Mapping | Business Analyst Skills | EP 1
ThePrefectBA video demonstrates how the BA uses the completed map to facilitate a discussion about release planning with stakeholders.
Watch from 11:17 to 13:40. Observe how they identify the stories for Release 1 (the MVP), then group the remaining stories into future releases (Release 2, Release 3).
This process of "slicing" the map is fundamental. It transforms the story map from a simple visualization into a product roadmap. This is a powerful communication tool for aligning the development team and managing stakeholder expectations about what will be delivered and when—a key responsibility in your project management experience that translates directly to the BA role.
Test your understanding!
You have just finished a story mapping workshop for a new e-commerce site. A key stakeholder insists that a "Gift Wrap" option, which your team has prioritized low on the map (near the bottom of a vertical column), absolutely MUST be in the first release (the MVP). What is the best way to handle this situation using the story map?
- Agree immediately and move the "Gift Wrap" story to the top of its column to include it in the MVP slice.
- Explain that the story map is final and cannot be changed after the workshop.
- Have a discussion with the stakeholder about trade-offs. Show them visually on the map that to include "Gift Wrap," another story of similar size/complexity currently in the MVP slice might need to be moved to a later release.
- Tell the stakeholder you will create a separate story map just for the "Gift Wrap" feature.
Show answer
Option 3 is the correct answer. The story map is a tool for facilitating conversations about priority and scope. By visually demonstrating the trade-off ("If we pull this story up into the release, we may need to push this other story down out of the release"), you make the consequences of the decision clear. This empowers stakeholders to make informed choices about what is truly most valuable for the first release.
- Option 1 abdicates your responsibility as a BA to manage scope and facilitate good decisions.
- Option 2 is incorrect; story maps are living documents meant to be adapted.
- Option 4 creates unnecessary complexity and misses the point of having a single, holistic view.
4. Practice Exercise: Mapping an AdTech Feature
Let's apply what you've learned. In the previous lesson, we decomposed this epic:
Epic: "As a marketing manager, I want to track the performance of my advertising campaigns in real-time..."
We created the following user stories:
- Story A: See a summary of total impressions, clicks, and spend for all campaigns on a single dashboard.
- Story B: Select a date range (e.g., 'Last 7 Days') for the dashboard.
- Story C: Sort the campaign list on the dashboard by spend.
- Story D: Filter the campaign list by 'Active' status.
- Story E: Export the current dashboard view to a CSV file.
Your task is to organize these stories into a simple story map and define an MVP.
Instructions:
- Define the Backbone: Use these high-level user activities for your horizontal backbone:
View Campaign Dashboard->Analyze Data->Share Report - Map the Stories: Place each story (A, B, C, D, E) under the most appropriate backbone activity.
- Prioritize Vertically: Within each column, arrange the stories by priority (most important at the top).
- Slice for MVP: Draw a line to define your MVP. What is the absolute minimum set of stories needed to provide initial value?
Show your proposed story map and MVP slice
Show a possible answer
Here is one possible way to structure the story map. Your prioritization might differ slightly, which is perfectly fine and a normal part of the process!
The Story Map:
| View Campaign Dashboard | Analyze Data | Share Report |
|---|---|---|
| Story A: See summary of impressions, clicks, spend. | Story B: Select date range. | Story E: Export to CSV. |
| Story D: Filter by 'Active' status. | ||
| Story C: Sort by spend. |
--- (MVP / Release 1 Slice) ---
Explanation:
- Backbone: The user first views the dashboard, then analyzes the data on it, and finally might want to share it.
- Mapping:
- Story A is the core of
View Campaign Dashboard. - Stories B, D, and C are all ways to
Analyze Dataon that dashboard. - Story E is a way to
Share Report.
- Story A is the core of
- Prioritization:
- Under
Analyze Data, selecting a date range (B) is arguably the most fundamental analysis tool. Filtering (D) is also very important for focusing the view. Sorting (C) is a useful refinement, so it's placed lower.
- Under
- MVP Slice: A strong MVP would include Stories A and B. This delivers the core value proposition: the user can see their key metrics (A) and analyze them over time (B). This is a valuable, shippable product increment. The ability to filter, sort, and export can be added in the next release to enhance the experience.
Conclusion
Excellent work! You have now moved from creating individual requirements to organizing them into a coherent product narrative and a strategic release plan. This is a massive step forward in your journey to becoming a proficient Business Analyst.
Key Takeaways:
- User Story Maps provide a two-dimensional, visual representation of the product backlog, showing the user's journey horizontally and priority vertically.
- They are built collaboratively to create a shared understanding among stakeholders and the development team.
- The most powerful feature of a story map is the ability to "slice" it horizontally to define releases, starting with the Minimum Viable Product (MVP).
- This technique transforms a list of requirements into a visual product roadmap, which is a critical tool for planning and communication.
Preview of the Next Lesson:
Your story map is a living document and the primary input for sprint planning and backlog refinement. In the next lesson, we will focus on how to contribute to backlog refinement (grooming) and sprint planning by clarifying requirements. You'll learn how to take the stories from your map and work with the development team to get them ready for an upcoming sprint.