Making A Story Map: How to Shape the Big Picture During Product Inception

One of the goals of Product Inception is to break down our vision into user stories and figure out how they fit together and which ones are top priorities. But how do we dive into the specifics while keeping all the most important goals of the product in view?

At this point in the Product Inception process, we've come up with a well-defined product vision, conducted stakeholder analysis, and acquired a better understanding of our users through persona analysis. Now it's time to grab our post-it notes, find a large, blank space like a conference table, wall, or white board, and assemble our Story Map. A Story Map synthesizes much of the work we've already completed during the Product Inception process and gives us a bird's eye view of what we're going to make and how the product is going to function. It's a visual and collaborative activity that's much more effective (and more fun) than a document that explains the product in plain prose.

Why Create a Story Map?

A Story Map is crucial to Product Inception because it helps us identify the features the product will have and the stories we'll work on. Walking through the map with a user in mind (or better yet, with a real potential user) enables us to pinpoint things we may have missed about the way a user interacts with the product in order to achieve their goal. A Story Map also allows us to decide which features don't serve the user's goal and are therefore out of scope. It gives us a working idea of what the minimum viable product would look like and allows us to plan the first release. ¹ In addition, a Story Map serves as a reference when putting together the product backlog.

A Story Map is highly useful beyond its application to Product Inception. When a team is in the throes of the development process, it can be easy to lose sight of the project beyond the next item in the backlog waiting to be completed. A Story Map helps everyone stay motivated by the big picture even when they are working on smaller pieces of the puzzle. A Story Map is also instrumental in keeping stakeholders on the same page as the development team. During a sprint review, a Story Map can be used to point out what features the team worked on, which gives stakeholders a concrete idea of progress. ²

How to Make a Story Map

Let's begin by thinking of a user persona and the goals they want to achieve with our product. Consider the internal app for college professors and students that we discussed in our recent post about persona analysis. A professor's goals could include creating a syllabus, uploading resources, creating a new assignment, and making an announcement. To start building our map, we write each of these goals on a post-it note and arrange them from left to right.

This is the top level of the map, and each post-it note is what Story Maps expert Jeff Patton calls a "user activity". These user activities represent epic stories that are often too large for a single sprint and usually involve a series of tasks that will make up the lower levels of the map. We can also place the user persona above this top level as a reminder of whose perspective we're considering. It's a good idea to color-code your map so that each level is a different color. Let's take a look at our map so far:

Our next step is to break down the user activities into tasks the user must complete in order to do the activity. Let's focus on "Create a new assignment." To achieve this goal, a professor must write the assignment instructions, set a deadline, choose acceptable submission formats (like doc or pdf files), and create a grading rubric. We arrange these tasks under the user activity, from top to bottom according to the relative importance of each task or the order in which a user would normally complete the tasks. We want to avoid going into too much detail, though; during Product Inception, our aim is to get a high-level picture of how the product will function.

We'll then repeat the process for each user persona. The Story Map is our opportunity to think big and try to include all the possible stories. Only when we have everything in front of us can we decide what stories to prioritize.

But how do we use the map to prioritize stories? The user activities on the top level of the map make up what Patton calls the "backbone"; these are the essential features the product must have in order to fulfill our vision. The prioritizing happens below this level. We make sure the tasks are organized with the most important ones near the top. We can then look at our map and draw a line where we see that the product would have all the features necessary for it to function. Everything above the line comprises the minimum viable product that could make up the first release; everything below the line can be left for future iterations. ³

A Story Map puts our vision into more concrete terms and serves as a guide throughout the design and development processes. We used a Story Map exercise during a highly successful Product Inception session at Amgen, and as a result we were able to estimate the effort necessary to create the product, as well as discover factors that saved valuable time and resources. We see the Story Map as an indispensable part of Product Inception and a very effective way to make sure we're creating something that truly centers users' goals.