‑ User Story Mapping
Story Mapping is a collaborative and quick method where you extract all interactions with the product from user scenarios. The end result is called a User Story Map, and that will be a total overview of the complete product (or the part you are currently working on) from the beginning to the end of the usage flow. The grouping of functions and content in activities gives the product owner a great overview over all possible solutions based on different personas’ needs. There can for instance be several solutions that creates the same result for the user, but they may differ a lot in cost and time to deliver.
It is a great tool for the product owner to get everyones understanding and contribution to the creation of the backlog based on user and business needs. It is the perfect discovery tool that can be used continuously throughout the product life cycle. The User Story Map can be used as a backlog where you slice your stories into minimum viable product releases, prioritize them and have great discussions together both with end users and developers.
The end result of a story mapping activity can result in a user story that looks somewhat like this:
At the top of the map are a sequence of activites or categories. These are the broad things that a user would do in the system. One user might administer the product catalog, this would be an internal user such as a sales person. Another user might order products, and this would be an external user such as a buyer.
Under each main activity, there’s a sequence of steps, the user scenario, that the user would do to achieve the main activity (purple above, yellow below). This is the narrative flow. For ordering a product, you first have to find the product, then select it and finally place the order. Possibly a lot of more steps are needed for the whole flow.
For each of these steps, there are possibly several different solutions as well as different things to build to achieve what the user wants to do (all kinds of colors above and white below). These are sometimes called tasks or more often stories. For instance, to find a product, you should be able to find it through browsing/navigating, perhaps it should be possible to search for it or you might find it through recommendations.
When you have explored possible solutions it is time to decide what we are going to build now, and what we are going to build later. You might decide that searching will not be a way forward at all, or that browsing and searching are complementary and thus both necessary.
Here’s an example of a story map (using a tool called StoriesOnBoard):
What we create is a map that lets us tell a really big story about the system. It’s important to build the map in a way that tell the story to everyone else. This will help them understand what your product is and a lot of great feedback will come out of that.
How to build a story map
This can be done in several different ways. This is the way proposed by Jeff Patton, who probably should be seen as the inventor of the user story map.
User story mapping is an activity that benefits from having a lot of people in the participating. It is a given to have the people who are supposed to build the project there, because during this session a lot of details get discussed and understanding grows rapidly. To gain maximum understanding, as many stakeholders as possible should also join in, and why not bring a user or two.
Frame the problem
First you need to understand the reason for building the product. Two essential questions to ask yourself is “why are we building it?” and “who are we building it for?”. It’s always good to have done some research in these two areas before, such as stakeholder and user interviews. Better yet, build an impact map together as a base.
Map the big picture
First you need to map out the sequence of steps the users will take. This is done by creating a future scenario, i.e. listing all the interactions that the user will do in relation to the product. It is very good to understand what the user does before and after interacting with the product, since this puts the product into a context of use and can help the user in other areas by expanding the product’s scope. One approach could be to explore current user journeys with users, find the pain points and possibilities and adjust them to become a future scenario.
Write down all the different scenarios that you can come up with. Think user flow, think ways of reaching a goal. Find problems that are likely to occur in the process where the scenario takes place. List the pain points. Ask yourself in what environment the scenario is taking place, this might affect what steps are taken. Decide on one scenario (per user perhaps) to focus on.
One way of doing this is to make the participants list what they think are the interactions by themselves, and then you combine all the scenarios on a wall in one long flow. Remove duplicates, prioritize steps, and end up with one given flow.
In the photo above, a group of story mappers are in the middle of creating one main flow by sorting similar activities in columns and different activities in a single row. A discussion is going on how to interpret the different sticky notes. Some of these notes might be stories already and not steps in the flow, so they are put below the row.
In the exploration phase you brainstorm solutions / stories to solve the steps. An easy way is to just write solutions on sticky notes and put the up on the wall under each step. A more complicated but rewarding way is to use the Design studio method to generate solution ideas by sketching.
Slice out a release strategy
The Minimum Viable Product (MVP) has emerged to find out if the customers are the least interested in a new product. A minimum viable product has the exact (not least) amount of features to make it desirable and sellable, thus giving value. It is created to maximize learning. The MVP is the minimal thing that can validate your hypothesis. What we are trying to find for the release strategy is a Minimal Feature Set, a sort of MVP, but often larger to function well as an actual release.
The not so lean approach is to plan building the whole product, like baking a birthday cake. First, a cake is created, this is a product that has the minimal but complete usage flow with a minimal but complete technical framework. It is nice, it is a cake. It shows that the product is feasible. It might say something about viability, for instance showing the cost for the developers to add a feature. It might also say that the interaction design is good. It is easy to add filling (features) since we have both the design and the technical frameworks. Sales persons will probably argue that to make it sellable it needs this and that feature as well, adding items to the feature list on a daily basis. What is missing is the icing. So, somewhere along the line, we find what is the icing, what makes the product desirable and interesting, but this has taken way too much time, so the competitors have won the race to fame.
Let’s start with creating a cupcake instead of a dry cake without filling and icing. The cupcake has filling and icing, but not so much compared to the cake. But, the cupcake is something that the customers want, need and love, so you can start measuring how much and if it is viable to produce.
After that you can easily expand your MVP to become a cake with filling and icing. And since you then know that you have a feasible, desirable and viable product, you can expand it to become a birthday cake and easily some time later a wedding cake.
Prioritization of the map is done by moving down stories that do not seem necessary to achieve the MVP. There can also be several different ways of doing the same thing, remember to prioritize based on what is sellable, desirable/usable and actually feasible. One story might cost a lot more to realize than another. Check your prioritization against your research of users and stakeholders, and create the MVP release and other possible releases after that by dividing the map horizontally.
You might find that some stories consists of smaller ones that will end up in different releases. Slice these bigger stories (often called epics) into smaller stories and place them where they fit.
Slice out a learning strategy
As noted before, the concept of the MVP was created to maximize learning. The MVP release will most likely take some time to build. It is based on a lot of assumptions, and if we could validate these assumptions as quickly as possible, we would know quicker what is sellable, desirable and feasible, and be able to steer the product towards success.
Ha Phan, product designer at GoPro, says “The MVP is the smallest nugget that matters. It’s not a cupcake, but maybe tasting samples.” These MVPs consists of investigations, prototypes and technical spikes, all experiments made to address assumptions, risks and challenges. Here are a few examples of these MVPs:
Slice the most risky stories into experiments.
Slice out a development strategy
Last thing to do is to do the actual work prioritization. Prioritize the most important things to start working on, slice the stories in this group that might be too big to be easy to understand, and then build a flat backlog of these items.
Now you’ve built a map of the whole product. Use it as a continuous planning tool, update it and use it for breaking out new backlogs when needed.