agile user mapping Is your goal to optimize your project management? Then agile user story mapping should become a part of your project management routine.

Story maps have a few lucrative benefits:

Clear priorities. Story mapping involves a certain structure, which also means better prioritization of your tasks.
Better goals and product vision. A story map is dynamic and helps visualize the goals of your project.
Improved communication. A story map is usually created by several teams. As a result, you’ll have everyone’s opinion included.

So, your team will obviously benefit from user story mapping. But how to do it the right way?

We will attempt to answer this question today as we discuss our five tips on mapping the perfect agile user story.

1. Start by Framing User Stories and Defining Goals

A good story map should always have clear borders. It should depict the current state of your product and not touch upon the features that are now in development or are planned for the near future.

Before you start writing user stories, your main goal is to focus on the product you have right now and bring it to life.

So, the first step in mapping a user story is actually defining the MVP – Minimal Viable Product, or an early version of your product with its most important features. To build this image of your product, you need to answer three basic wh– questions:

What? What problem are you trying to solve with your product? What are the needs that your product can fulfil?
Who? Who is a typical user of your product?
Why? Why is your product the one for the typical user, and which benefits will it bring them?

Once you have the description of your product, you can proceed to outline the main MVP features. Here’s an example:

When you have all your product information categorized, it will be easier to understand and set your goals.

How to connect product information with your project objectives?

Determine the goals each product feature can solve. Summarize all hypothetical goals your buyers might have when purchasing your product and align them with respective product features.
Put your goals on index cards. Try to be clear and concise when describing each goal.
Organize index cards in a logical order. Each goal should represent a stage of a customer journey:

Once you have your goals in place, it will be easier for you to move forward with writing user stories.

2. Build User Personas

Another basic feature of a user story map is a user persona. Hypothetically, you could write stories about random product users, but it would lead you nowhere once you start breaking down your map into activities.

The description of a user persona typically consists of the information on:

age
gender
background (job, income, education)
spending habits and behaviors
psychographics (goals, needs, pain points)

The trick here is that this information may vary depending on the type of personas: a buyer may be goal-oriented or role-based. You might also want to build engaging personas (the combination of the two previous types based on user psychology), and fictional personas built on assumptions from previous experiences with users.

Which persona type should you choose for your user story map?

There’s no definitive answer. Depending on your product, you might find that all four persona types are suitable for your project.

But, whatever your situation is, there are two principles you should follow when building a buyer persona – focus on data and on prioritization.

First and foremost, you need to define your user persona with data you already have. Brainstorming is good, but your ideas need to have solid ground. This data should not only include customer behaviors and previous consumer experiences. Competitor analysis and product research should also lay the foundation of your user persona description.

The next thing is prioritization. You already know that you can involve all four types of personas, but not all of them will play an equal role in your user story map. That’s why you should rank them from most to least critical.

3. Write User Stories

Now, it’s time to start writing user stories. The goal here is to build the backbone – the structure of your map that captures the main activities the end-users will perform when using the product.

Depending on the scope of your project, you might need to write several user stories. Linda Ferguson, the CEO of the flashcard database https://subjecto.com/, says her company created up to twenty user stories before the launch of the service, which helped them create a more diverse user story map.

Regardless of the number of user stories you are planning to write, they should always consist of three main components:

User needs. Start each story with a specific reason why a buyer would give your product a try.
Product feature connected to the story. Mention whether a story is tied to the entire product or a specific feature. It can be especially helpful for massive product launches.
Outcome. Conclude with the results users will get from using your product. This will help your team focus on goals rather than individual product features.

In the end, your task is to analyze all the user stories and unite them into the backbone of your map:

Even though some of your users might do things differently than described in the backbone of the map, your goal here is to determine the ideal user flow, not go too deep into details. Nevertheless, still keep each individual case in mind.

4. Break down User Map into Activities

When mapping user stories, you’ll notice that some of the steps can be put into similar categories. These steps are called activities.

Typically, the structure of a user story map consists of three main elements:

Activities (we mentioned earlier) – high-level tasks users perform with a product.
Steps – actions users perform to complete a specific activity.
Details – smaller actions involved in each step.

So, let’s say your user wants to check the account balance. This is a high-level task or activity.

Which steps do they need to go through to their balance? Probably they will first log in or sign up and then access their accounts. These are the steps.

But what do they need to log in? They enter username or email, password, press the login button and then view account balances. These are details.

Now you have a general idea of how you can break down your map into activities. But there are several routes a user story can take. For instance, when logging in to the account, a user might want to restore the password or press the Remember Me button to save account details. It is important to include all possible deviations to keep your map complete.

5. Revisit Your Draft Several Times

You’ve finished your product map, or at least it seems like it’s complete. What now?

It’s too early to start acting yet. One of the most common agile story mapping mistakes is trying to bring your map to life too soon. It might be tempting to jump in right away, but you’ll discover very quickly that your map still has gaps in it.

Why does it happen?

Mapping a user story is usually not a single-day activity. Experienced project managers get their teams together several times before they deem a user story map complete.

The reason why these maps don’t like haste and rush is that user stories require thorough research that involves data. This data may still be coming in real-time and change your perspective on some user stories.

So, take your time and revisit your map a few times before you put it into action. You might discover new activities to add or find a better way to prioritize your stories.

Wrapping Up

Sometimes, it might be tempting just to map agile user stories based solely on brainstorming. After all, if you know your product and your customers quite well, why can’t you build a map just off the top of your head?

You could, but it would hardly come out good. Mapping the perfect agile user story is about following a structure that reveals exactly what your map should include.

Let’s quickly recap the agile user story mapping process:

Frame your user stories and set goals. You can do it by defining your product and its key features first and then move forward to identify your objectives.

Build user personas. You can include several types of agile user personas in your map, but make sure to build them using data and prioritize their roles.
Write user stories. Mention the needs that drive users to your product and how your product or its particular feature would solve them.
Break your map into activities. This way, it will be easier for you to organize your work later.
Revisit your map. In case some new data comes up, you might need to update your map to make it more complete.

Don’t aim for mapping the perfect agile user story right away. Give it time – Rome also wasn’t built in one day.

This article does not constitute legal advice.

The opinions expressed in the column above represent the author’s own.

Start managing your legal needs with Zegal today