Story Mapping: This is How It Works and How You Benefit From It

Imagine having a tool in your hands that gets you into the mind of your product’s potential client, predicts his behavior, and directs him to the outcome you’ve prepared for him?

Story Mapping is a method devised by Jeff Patton that helps you to provide a clearer picture of the User Stories. This allows you to obtain a better product backlog and ensures that an Agile (Scrum) project runs better. Story Mapping is a visual tool that ensures that the software works more efficiently and corresponds better with the wishes and expectations of users. Read how it works and how you can use it to your advantage.

Let’s first consider a number of issues concerning the development process. A Product Backlog is often used, which contains all of the required functionalities of a product. These consist of the earlier mentioned Epics (the larger goals) and ‘stories‘ (sub-goals of the bigger goal).

An Epic is for example: making sure that the (mail) inbox is managed. In this particular example, stories would be: deleting, answering, and drafting emails. Mapping these stories, preferably in the most functional way, is what is called Story Mapping.

By applying Story Mapping, you place yourself into the mind of the user. This allows you to develop specific functionalities. Additionally, it is possible to cut a larger project into smaller projects. This makes a joint approach easier and allows functionalities to be divided into smaller releases. As a result, this provides the opportunity to create more- and faster iterations. Altogether, this makes it an overall effective method.

Story Mapping consists of the four steps explained below. To make these steps more clear, we apply them to a product that you may use in your daily life, such as the ‘Appie’ app from the supermarket Albert Heijn.

# Step 1: the concept (the question behind the question)

It is logical to assume that it is necessary to develop an app, one-pager (a website that does not consist of sub-sites, but scrolls through at once), or a different type of product. Instead, you should first ask the question behind the question. The goal is often confused with the tool. Focusing on the tool is often not the solution. This is how you focus on the question behind the question:

– What is the problem you want to solve? (That is the question)

– What is needed? (The question behind the question)

In the case of the Appie app, the problem would be the gap between the digital and the physical store. To get consumers to the store, it is necessary to communicate information about the different stores, offers, and other relevant content. Albert Heijn already offers that: the Allerhande recipes can also be found in the Appie app.

# Step 2: Identify users (personas)

More than once an app version of a website has been created, which did not meet the desires of expectations of the target group. That is why it is necessary to work with so-called personas. These are the (desired) users of the product that is being developed. It is quite possible to have different types of users and therefore to work with various personas.

In the case of the Albert Heijn app you could make a distinction between daily users (such as families) versus irregular users who are for example more driven by discounts. How can both groups have a mobile user experience in the same application? Does the result of the Story Mapping continue, while keeping both target groups (or personas) in mind? We strive to identify as many personas as possible so that no potential user is forgotten. Note that the admin is also a possible user.

# Step 3: First the main lines (Epics)

The development of a digital product starts with determining the functionalities. These larger goals are called Epics. It is a bit of a weak play on the word Story (the smaller goals or functions) because it expresses a story that would be “epic” or large. However, an Epic helps to bring context and perspective to the Stories and contributes to the development of the Stories. It is not a coincidence that the Epic is compared to the backbone and the Stories with the rest of the skeleton: one “sprouts” from the other.

The ‘Appie’ app makes it possible to search for locations, recipes, assortment and bonus deals. These are functionalities that can be understood by everyone. The Epics further disintegrate into smaller Stories, such as for example scrolling through filtering the different recipes for allergies or ingredients.

# Step 4: The Stories (mapping)

“Stories” can be found under the Epics. This applies in two respects. An Epic can be broken down into different Stories: it is the combination of all individual functionalities that makes it possible to work as a complete whole. With Story Mapping, the Stories are often physically placed under the Epics.

Do you want to make it possible for visitors of the Appie app to search the physical stores of Albert Heijn? The following Stories are then required for this: (being able to) determine the user’s location, loading a map / Maps environment, displaying stores, displaying information about stores, and making it possible to search for the location of the stores.

Sticky notes are still one of the best means to get a nice overview of the whole of epics, stories and then to set priorities

# Step 5: Set priorities

The inventor of Story Mapping, Jeff Patton, thinks it is nonsense to make some Epics (parts of the backbone) a priority. Compare it to the development of a car, where you also make no distinction between the development of an engine or brake.

However, under these Epics, at the Stories level, it is necessary to set priorities. Make a distinction between four levels of urgency and call it – following the MoSCoW method – a difference between:

M – must haves: necessary;

S – should haves: desirable but not necessary;

C – could haves: what is covered if there is enough time;

W – won’t haves: what is discussed in a subsequent iteration or project.

Just as the developer of a car considers whether, for example, he would like a 4 or 6-cylinder engine. Naturally, the MVP – the minimum viable product – is one that contains as many Stories as possible with the denominator “necessity” and as little as possible with the denominator “possible” – the 4-cylinder engine in this case.

To show a user of the Appie app if there is a store nearby, it is not necessary to provide much information about the store. An MVP of this functionality, therefore, focuses on requesting the user’s location, loading a map/maps environment, and displaying stores that are nearby.