What is Story Mapping?
Story mapping is a method for arranging user stories to create a more holistic view of how they fit into the overall user experience. Arranged on a horizontal axis, the fundamental steps of the customer journey (sometimes labeled as epics, sometimes not) are arranged in chronological order based on when a user would perform the particular task relative to their overall workflow with the product.
Individual user stories are arranged beneath the more significant steps they roll up under. Thus, when a story map is complete, you can see all of the ways a user might interact with a product in a single, logical view that progresses from the first interaction to completing the overall user objective.
Story mapping is usually done on a wall (or floor) using sticky notes or index cards and many tapes. Usually, the entire team identifies and agrees on the primary steps of the user journey and then assigns user stories beneath them. Finally, each story is discussed, so there’s no doubt about what a story actually is, its purpose, and how it fits into the overall scheme of things.
Why Use Story Mapping?
Story mapping serves a few key purposes. First, it paints a full picture of how a product is used, often lost in the “not seeing the forest for the trees” reality of feature development since most teams focus on specific tasks and not the “big picture” most of the time. Second, it can also identify holes in functionality or areas to focus on since they can visually highlight gaps in the user experience. Finally, a story map can also be an excellent tool for prioritizing, both for an MVP (the minimum required to complete the overall goal) and subsequent releases (what’s missing that must/should/could be there).
Of course, 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.
What’s the History of Story Mapping?
Jeff Patton is credited as the inventor of story mapping, and he has written the book on it (User Story Mapping). This invention was born out of a realization that written documents are prone to misinterpretation while having an actual conversation was far likelier to lead to a shared understanding and delivery of a product that meets the needs of its intended users.
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 dubbed “story mapping” until 2008. However, in the decade since its introduction, it has been adopted by many agile adherents and incorporated into multiple tools and software solutions for product development teams.
How Does Story Mapping Work?
The backbone of the story map is the core set of steps a user must work through to accomplish their goal. Beneath each step are the details for each of the larger steps (the “big” step might be “checkout,” while smaller steps below could include inputting/selecting the shipping address, select a shipping method, inputting/selecting a payment method, confirming shipment, sending shipment details, etc.).
What really makes story mapping work is its reliance on visuals as part of an interactive, collaborative process. Reviewing a PowerPoint or scrolling through JIRA is a passive experience that, at best, will inspire a strong reaction from the audience—I agree, I disagree, that’s wrong, etc.—but seldom leads to a real conversation.
Story mapping is inclusive and interactive.
Story mapping invites everyone to “get their hands dirty” because the map is built in real-time, in-person, and collaboratively. As stories are being mapped to the overall workflow, there is ample opportunity to challenge, add, and edit, all relative to the overall goal and not focusing on a discrete task or item.
By working on the story map together, you create a shared understanding. Everyone who exits the session is on the same page regarding what’s important, why it’s important, and how it fits into the overarching goal. And since you’re not allowed to “move on” until each user story and how it plugs into the overall narrative is fully understood by everyone, you’ll avoid countless wasted hours of developers and designers creating things they “think” meet the objectives yet fall short in reality.
Story maps are never “done.”
Story maps are continual works in progress. As steps are completed, new ones get prioritized, and additional steps are added. Meanwhile, user feedback and competitive analysis uncover new requirements. So whether you leave your story map up/out and update it or rebuild it from scratch periodically, the backbone and key steps remain part of the process.
Reassessing your story map regularly is healthy and recommended. You can either leave it up on the wall permanently, or you can periodically recreate it, which in and of itself can be an insightful exercise. However you do it, the perspective gained from the process is invaluable, both in optimizing the prioritization of user stories and from the discussions and revelations that come from discussing each story with the entire team.
When Should You Use Story Mapping?
The great thing about story mapping is that you can start using it during any phase of the product life cycle.
- Working on an MVP? A story map is a great way to identify the minimum functionality you need to test your concept. It will prevent you from “forgetting” about critical parts of the user experience you might have otherwise overlooked.
- Trying to figure out how to improve on version 1.0? A story map can visually display all of the potential enhancements you could add and help your team have quality conversations about what will most impact your users.
- Managing your backlog a growing concern? Story mapping helps you tame the backlog by giving each item some context and forcing prioritization and grouping with a big-picture view; plus, it can highlight gaps you might have never noticed otherwise.
- Branching out with a new product extension? A story map will illustrate what you already have and the missing pieces you’ll need to make the new functionality work just as well as your current offering.
Regardless of whether your product is still theoretical or has been kicking around for decades, story mapping starts with personas—you must know who will be using your product and what they’re trying to accomplish. This drives everything in the future, as you’re envisioning how they’ll use the finished product before you’ve even built it.
And as your thinking matures, you’ll need to apply multiple personas to the same story map, as different types of users are trying to accomplish multiple things with your product. If your journey isn’t accommodating them all, this process will quickly identify your product’s shortcomings in these new scenarios.
What Are a Few Ways to Use Story Mapping to Prioritize Roadmap Initiatives?
Story maps provide excellent input to the roadmapping process. With every potential feature already mapped out and prioritized, you can essentially cluster the highest priority features into releases based on your team’s bandwidth and release cadence.
1. Sizing things up
Complete your story map with the smaller items arranged top-to-bottom based on importance. Then, collaborate with product development on assigning each item a relative level of effort (LOE). This could be person-hours, days, or weeks, or you can utilize some other system that gives the product leader a sense of how long each thing will take.
This is also the appropriate time to cluster any items that may benefit from being built simultaneously because it will increase efficiency. While this shouldn’t always dictate that all related items should be built simultaneously, it is one more tool to avoid prioritization and scheduling features in a vacuum.
Now that you can visualize both what is important for each major step in the backbone and how big of an effort each one requires, you’ll need to know how much actual work fits into a given release. For example, you may have a development team of five and a release cycle that where each developer has 50 person-hours of development time for new features, giving you 250 hours to work with.
2. Slotting things in
Now armed with your development “budget,” the ranking of each item, and the LOE cost of each item, you have enough information to start slotting items into releases for your roadmap. At this point, the story map has already done a lot of the heavy lifting, and you’re essentially working top-down from the backbone to see how much you can fit into each release.
The “art” comes in deciding how to allocate items to releases. You can take an egalitarian approach where each major step gets a relatively equal number of sub-items each release, or you can decide to focus on a specific step or two for a given cycle.
The latter approach may make sense for a product in its infancy (when you’re just trying to get a baseline of functionality into place) or when a product is quite mature. You’re just focused on iterative improvements throughout the process—taking a deep dive on a particular step or two (such as focusing on the shopping cart” may be a better fit for a product that’s already working but is ripe for significant enhancement and can benefit from concentrating on one area at a time.
3. Defining outcomes
Once you have decided what to include in each release, it should map to a particular outcome. In short, what should this release accomplish in terms of user experience? For example, it could be frictionless account creation or receiving personalized product recommendations.
Since every sprint has a desired outcome, it’s pretty easy to determine whether the sprint is successful. So, for example, if the objective was that users can now pick what color they want their widget to be, there’s a binary measurement of whether that outcome was achieved instead of celebrating that the color wheel shipped.
4. Iterating in plain sight
When a feature is too big for a single sprint, construct it iteratively. Don’t build pieces that won’t function until several sprints into the future. Instead, build the bare necessities first. Then, build out on that skeleton during each sprint while learning from real-world usage of the first iteration.
This allows you to quickly get that new functionality to market while still improving your design and execution on user feedback. It also cuts down on sprints that “lay foundations” but don’t deliver any actual value to end-users.
Story Mapping is One of Many Prioritization Tools
Story mapping is an opportunity to achieve many objectives that product leaders often struggle with. You can communicate big-picture goals and objectives without “lecturing” to your coworkers. You can create a collaborative environment that engages everyone to participate in product strategy. You can tap the potential ideas and concepts that might not have otherwise seen the light of day. And you can achieve consensus and understanding of objectives before your team writes a single line of code.
However, story mapping isn’t fast—you’re mapping every user story after all—and you’re going to need the right physical space to do it. You might have to convince management that this is a worthwhile use of everyone’s time instead of their usually scheduled programming.
But at the end of the day, if your product isn’t helping customers complete their journey, they’re going to take their journey somewhere else or cancel it altogether. A story map aligns everyone with that objective and creates a context-rich environment where it’s easy to see where resources should go.
See also: Kanban Roadmap, DACI Decision-Making Framework, RICE Scoring Model, MoSCow Prioritization