How to Use Story Mapping to Define MVP Requirements and Align Teams

Over the course of my career, I have had the pleasure of building multiple products from scratch, and have collected some strategies that help the process of building a new product and lead to a highly productive and streamlined experience for all stakeholders involved. Story mapping is one of those.

For me, Story mapping had become by far the most impactful exercise to align the entire team and have a point of reference that can inform not just engineering and product management, but also marketing, operations, user research, design, and business stakeholders.

In a nutshell, Story mapping helps you define the early versions of your product, and can be used to elicit use case requirements, edge cases, and the overall scope of go to market efforts, by consolidating major themes of work and their interconnectedness. You can get a detailed understanding of the process on this seminal post by Jeff Patton.

Let’s take the example of a simple note-taking app. The core use case is simply that the user can take notes and retrieve them when they need. At the same time, in order to deliver this functionality to the user, the app must be packaged into a web app and/or a mobile app. It’s safe to assume that the app will be delivered through the Google PlayStore or the Apple iTunes store, which means you would need to go through the app packaging and submission process for the respective app stores. While this last part is not the core use case, it is needed none the less to actually make the app available to users.

In this case one big theme of work will be “note taking”, and another theme would be “publishing the app” to the respective app stores. You can imagine how each new functionality to be built around the core use case could become its own theme in the overall Story map.

A Story map, is in essence an actionable version of the User Journey map. You can take the major activities that a user performs as themes for the Story map and fill in the details in the stories below.

In short, in order to build a credible Story map, you would need to identify the big themes, and then add User Stories to each one, giving you a sense of the work to be done. You can then go ahead and plan your work in Kanban, Scrum, or any other execution framework of your choice.

To make things clearer, let’s look a real world use case of building an e-scooter service, and the themes and stories involved.

This example shows a very detailed Story map for an eScooter service, with the core use case of “users can ride the scooters”, and secondary use cases such as analytics, and notifications, which are used to provide a better service to the user. The green lines below some stories show the cut off for the MVP i.e. stories below the green lines were considered out of scope for the MVP.

The product Story map starts to pay off right off the bat, when you create it. By involving design, engineering, product management, and any other relevant stakeholders, you can easily tease out the main requirements for the product AND gain instant alignment, that will continue to streamline your work throughout the product build phase.

The best way to create such a Story map is to do a workshop with all the parties involved, and move around sticky notes as needed. Fast forward a couple of hours, and you have essentially consolidated the major expectations of the product, and can even go further to break down the stories into items that can go straight into the backlog.

If your Story map was created on a portable medium e.g. sticky notes on a big piece of cardboard, it makes it incredibly easy to simply bring it to your sprint reviews, so that the Sprint work can be directly put into perspective, and all stakeholders can see the overall progress in a coherent visual. In the above example, you can see the green stickies representing stories that have been completed, yellow for work in progress, and red for stories that are yet to be started.

In an ideal world, a big wall, and some coloured sticky notes would be the best tools for creating a Story map. You can use bigger sticky notes to denote themes, and medium size sticky notes to denote the stories. But in case, you’re working with a remote team, or need a digital representation, Miro, Mural, or plain old Spreadsheets would do the trick.

While the initial Story map will get you started, it is vitally important to update your Story map as new learnings happen, so that the reference point is always up to date and can be used not just for your core team, but also to communicate to all relevant stakeholders. Make sure to involve all parties in the beginning i.e. design, marketing, business, operations, etc; and also to take in their feedback and update the Story map on a regular cadence.

Once your Story map is created and agreed upon, go ahead and map it into your day to day execution framework e.g. Scrum, Kanban, etc, and the tools you use for the same.

Have you used Story mapping to define your product and align your team? What was your experience with it? Let me know in the comments below!