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 larger steps they roll up under. 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 the completion of the overall user objective.
Story mapping is usually done on a wall (or floor) using sticky notes or index cards and a whole lot of tape. Usually, the entire team takes part in identifying and agreeing on the primary steps of the user journey and then assigning user stories beneath them. 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. It paints a full picture of how a product is used, which is 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. It can also identify holes in functionality or areas to focus on since they can visually highlight gaps in the user experience. A story map can also be an excellent tool for prioritizing, both for an MVP (what’s the minimum required to complete the overall goal) and for subsequent releases (what’s missing that must/should/could be there).
Of course, the most common usage of story mapping is utilizing 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.
History of Story Mapping
Jeff Patton is credited as the inventor of story mapping and he has literally written the book on it (User Story Mapping). This invention was borne out of a realization that written documents are prone to misinterpretation while having an actual conversation was far likelier to lead to a common understanding and delivery of a product that actually meets the needs of its intended users.
The goal of story mapping is to uncover the details of what is really required to deliver customer value and to 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. 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 Story Mapping Works
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 being 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 to 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 and 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 added. Meanwhile, user feedback and competitive analysis uncover new requirements. 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 on a regular basis 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 to 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 can help your team have quality conversations about what will have the most impact on your users.
- Managing a thriving, going 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 what are 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 is going to be using your product and what they’re trying to accomplish. This drives everything going forward, 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.
How 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.
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 at the same time 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 as well as 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.
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 and 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.
Since every sprint has a desired outcome, it’s pretty easy to determine whether the sprint is successful. 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.
Iterating in plain sight
When a feature is too big for a single sprint, construct it in an iterative manner. 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 a customer complete their journey, they’re going to take their journey somewhere else or simply 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.