Story Mapping: how to map product features around user needs

After reading a user story, the team knows why they are building, what they’re building, and what value it creates.

User stories provide an excellent way to define your product with clarity.

# Story Mapping is your magic tool

• • It is a method and a visual tool devised by Jeff Patton. When managing software development projects, Story Mapping is used for planning. In this article, I will mostly emphasize its benefits for business and why you should spend time with your development team on that.

    One thing entrepreneurs often forget: you are not your ideal customer. Neither is your development team. However, you want to know who your ideal customer is, and how he behaves while using your product.

    As a product owner and creator, you want to analyze certain behaviors your users manifest while using the product, and what type of problem they try to solve. When you convert behaviors into a sequence of steps, put them on the stickers on your wall, and link and map all of them in the most efficient and functional way, you get a comprehensive visual map of your future product.

• • Isn’t it a great way to look into how an individual user journey fits into a whole global experience of your product use?

• • Clearly designed stories help you guide the user towards his goal using the shortest path. Moreover, Story Mapping will allow you to build assumptions, test new features among different user personas (I’ll elaborate on that later) and do all sorts of experiments with possible users. While building Stories and mapping them, you may develop and introduce functions that you have not thought of before.

    Just as much as you, we want to understand your client, to make sure we deliver a final user-friendly product. Our goal is to make iterations faster and more often. Together with you, we can cut a larger project into smaller ones, for an easier joint approach and divide functions into smaller releases.

    So from the developers’ perspective, after a Story Mapping session, we get a clear list of the User Stories, to be decomposed further into features for your product. With Story Mapping, we architect software that works more accurately in accordance with your users’ expectations and wishes.

    Further features are decomposed into functions and tasks, and form the product backlog. I will be using a few terms for our convenience further in the article to describe some of the functions in Story Mapping.

    Among these functions are:

    · Epics. These are your large goals and fundamental steps of the product.

    Example of an Epic: a managed mail inbox

    · Stories. These are sub-goals of a large goal (of an Epic)

    If I continue with the example of the above Epic, its Stories examples would be deleting, answering and drafting emails.

    To sum up the above, there are two main benefits of Story Mapping, that can create that magical synergy during development a product:

    1. You understand your client journey better, which gives your product more chances to succeed on the market
    2. The process of development goes smoothly, iteratively, and avoiding time and costs waste

    Given the above, for me Story Mapping in Agile is a very effective method overall, and especially for an MVP which I will detail in the end.

# A real-life example:

Now I will break down step by step on how exactly Story Mapping works and to make it a simple read, I will use as an example a product we have successfully worked on: Support Points. It is an online digital platform that connects clients from manufacturing with PLC (Programmable Logic Controllers) problems with experts who support malfunctioning PLC’s and software modifications.

# Step 1: Define the concept, the question and the question behind the question.

No matter if we develop an app, a one-pager website or another type of product, it is very common to confuse the goal you are trying to achieve with the tool you are trying to make. Focusing on the tool is not the solution.

To avoid this confusion, I would recommend asking two core questions:

What is the problem you are trying to solve? (this is the question)

and then…

Why do you need to solve it? (this is the question behind the question).

With *SupportPoints the problem* we are trying to solve is providing machinery operator with a 24/7 access to instant PLC support in case of equipment outages.

Why do we want to do this? Because the operator needs to keep his production line running instantly.

To solve this, we develop a comprehensive way to connect customers with SupportPoints. We want to make sure we showcase it clearly by means of design elements of the website, where every element will answer the next “why” question.

# Step 2: Identify Story Mapping personas (users)

Different users login into the system to perform different operations. In case of SupportPoints there are few types of users: one can be looking for an immediate solution to a technical problem, another can be looking for an expert in a certain field, etc. Admin, who is managing the content of the system, or replies support tickets is also a persona to keep in mind. These are examples of co-called personas — the desired users of the product in process.

Our goal is to identify as many story mapping personas that no type of user is left behind.

Identifying user personas for SupportPoints

# Step 3: Start with the trunk of the tree — Epics

Developing a digital product starts with defining the functions, the above-mentioned large goals, aka Epics. The word speaks for itself: it is a story that is “epic” and large.

An Epic helps bring context and perspective to the Stories (smaller and more defined goals) and contributes to their development. This is why they call Epic the backbone and the Stories — the rest of the skeleton.

What we did with Epics for SupportPoints is defined what SupportPoints does and the clear operations the defined above personas need to perform. Then we highlighted them on the main page, making them visually very clear.

Epics in orange with their respective Stories in pink below as an example

# Step 4: Continue with the branches — Stories

Stories are under the Epics both metaphorically and physically. First, you can break down an Epic into different Stories — individual separate functions which make it possible to work as an organic whole. Second, in Story Mapping itself, Stories are physically placed under the Epics.

This is an exceptionally interesting process we encourage you to take part in. Very often a product you imagine doesn’t end up exactly as the product you had in your mind: user persona behavior may reflect on iterations, changes and adjustments.

Together we can take a step back and take a look at the big picture of Epics and Stories based on the user who is in the center of the process.

We use sticky notes on a white wall and rearrange the workflow and the priorities in the most hassle-free way.

Here is how we’ve done it with SupportPoints:

For example, on the highest level, we broke down the Epics into: Main Page — Registration — Finding an Expert, etc. — the list was long and then each Epic had its Stories below.

Main page

· Info

· About

· How it works

· Etc.

It was a wall covered in dozens of sticky notes which turned into a very well thought-through project. As I mentioned above, the biggest advantage: you see a map of how a particular persona uses your product, and integrate your ideas along the way.

When we work on this Story Mapping wall, we analyze why a user persona behaved this way, why he skipped a feature or why he chose to stay longer on a certain page. We decide together whether we should leave out some parts because they are left untouched by all the user persona groups. You may have a new vision when you see how a user reacts to a feature

As a result, we plan the project together, we plan it better and no party is left behind, we are in this hand in hand, and as the product owner, you know exactly what is happening to your product and it is mapped out in the best possible way.

An example of Story Mapping in progress for our project

# Step 5: Set the priorities straight

As attractive as Story Mapping is, you have got to start somewhere and somewhere right. Here I agree with the inventor of Story Mapping, Jeff Patton, who thinks it’s nonsense to make certain Epics a priority.

Think about building a car where you will also make no distinction between creating an engine or a brake. In Epics, everything matters.

However, at the Stories level, I highly recommend you set priorities. I am a strong believer in* the MoSCoW method,* where you arrange your Stories in four levels of urgency:

M: Must haves. Absolutely necessary

S: Should haves: Desirable but not vital

C: Could have: Can be covered if there is enough time left

W: Won’t haves. Not planned in the current iteration or project but may be discussed for the further ones.

This is how we finalized our process and set up the first priorities:

Example of first priorities in Story Mapping

So, why Story Mapping in the end?

As I have explained, Story Mapping makes it way easier to gain insight into the development process. Even better, the process becomes clearer not only to the Product Owner but to all the team. It is easier to correct mistakes in the process, adjusting them to the user’s wishes. With Story Mapping, you are far more likely to launch a product that meets the users’ expectations and needs. Eventually it helps our clients to see clearly the system of how the project will be implemented.

Another bonus is that the software that has “been through” the Story Mapping process is less likely to malfunction because certain Stories don’t connect with each other — it is faster to work with small iterations and bring it to the MVP.