User Story Mapping or User Scenario Maps

What is User Story Mapping?

User Story Mapping or USER STORY MAPS is a way to visually plan and prioritize tasks. The good thing about this method is that it forces us to think about our software solutions from the perspective USER STORIES(User Story).

Before we get to know the method, it is important to understand what it is USER HISTORY.

What is a User Story?

USER HISTORY – this is a description of a product feature, told from the point of view of its user. Literally a story about how exactly a feature is used by a specific user. USER STORIES When describing the functionality of a software product, the user is put at the forefront.

When writing USER STORIES The following scheme is often used:

As a [type of user],
I want [some particular feature],
So that [some benefit] is received.

In Russian, this diagram will look like this:

Как [тип пользователя],
Я хочу [описание какого-то действия],
Чтобы [описание цели].

When compiling USER STORIES It is important to understand what level of detail you need. For example, the following story is a bad example:

Как клиент онлайн магазина,
Я хочу купить товар,
Чтобы им пользоваться.

Why is this example bad? Let's close our eyes to the fact that the example was taken from our heads and the description of the goal is a bit strange. The main problem with this example is that “I want to buy a product” is too big an action to describe in one story. “Buy a product” usually means:

• open an online store website

• find the right product

• view its characteristics

• read reviews on it

• add it to cart

• log in to save your purchase history

• enter bank card details

• pay

Why is it important to choose a comfortable level of detail? USER HISTORY? Because the main benefit of the method USER STORY MAP is to plan the delivery of functionality in small parts. This allows you to move from one small release to another, in frequent steps, to arrive at the user’s final goal, implemented in the form of a software solution.

Huge stories are extremely difficult to plan because, due to their size, they will immediately take a lot of time and planning their partial delivery will be problematic. Therefore, it is a good practice to break large tasks into separate stories. Above I have already given a list of actions that are part of the “Buy a product” action. Each of these small actions will be a separate story.

What does User Story Mapping look like?

So now that we understand what it is USER STORIESit’s time to figure out the methodology that actively uses them.

So, let's try to make our own USER STORY MAP. And for this, first of all, we need to understand exactly what feature we will model. Since we are talking about purchasing goods in an online store, let's continue with this example.

USER STORY MAPthis is a visual modeling and planning method, so to visualize my story, I will use the Miro service (Online Whiteboard & Visual Collaboration Platform | Miro).

The story consists of several steps performed by the user in a certain sequence. Therefore, to our electronic board, first of all we will add our user.

Frame

Next, in order for our story to look like a meaningful narrative, we need to tell what our user does and in what sequence. To do this, we will add the main actions in the user history in the form of separate stickers and arrange them in the order in which they were performed, from left to right.

We ended up with a list of small goals that the user is trying to achieve at each stage. If we try to tell a story, a narrative, using these cards as clues, then we can easily succeed. This will be a story about how a Client of an online store orders a product. This is an example USER HISTORY. However, USER STORY MAP It doesn't end there.

What we just did, this set of stickers that make up our story, is called FRAME (or Backbone, in foreign literature). It is he who is the basis USER HISTORYand it is on this that we will layer the remaining elements, namely, generate small stories in the format of tasks, as well as highlight parts of something unified.

Next step, let's look at the orange stickers. Although each of them describes a unique step for the user towards the final goal, they also have common elements. For example, “Enter bank card details” and “Pay for the order” refer to a larger action, namely “Pay for goods”.

One more nuance that I want to mention right away is USER STORY MAP must be a living document. Its contents should be discussed, changed and kept up to date. It's absolutely fine to work on it iteratively, changing its content and order of operations to reflect the vision of exactly how the user should go through our software solution before reaching the final result.

So, after the next iteration, our map began to look like this:

The attentive reader will notice that blue stickers have appeared on the map, which represent more general steps and are called ACTIVITIESand also, the order of some orange stickers has changed.

But that's not all. For now, we're just organizing our view of user actions. We write the story itself. However, since USER STORY MAPS is also a task planning tool, it’s time to talk about it.

Tasks

Each of the orange stickers describes a big step towards the final goal. Moreover, each of them may contain several sub-steps or even different versions of the same action.

These sub-steps or options are called in this method TASKS and are displayed in the vertical axis, below FRAMEWORKusing stickers of a different color.

Each TASK refers to its element FRAMEWORKand describes some small action, the purpose of which is precisely the element FRAMEWORK. Quite simply, stickers with tasks are placed under the orange stickers to which they relate. Each of the task stickers is USER HISTORYwhich can be passed to the developer.

In the case of my map, task stickers might look like this:

There is one simple trick that will help you describe tasks so that:

• they all had a similar semantic structure

• and so that all participants in the modeling understand very precisely what needs to be done and why. Exactly from TASKSsubsequently tickets will be created for the developer.

So, the trick is the following – remember the scheme according to which USER STORIES: As a [user], I want [something], So that [achieve some benefit] Now let’s change it a little, replacing general terms with map elements:

As a [user],
I want [task],
So that [backbone element]

My scheme is written in Russian, so let's, following this scheme, try to compose several stories for the developer:

1) Как клиент онлайн магазина, Я хочу использовать строку поиска, Чтобы найти нужный товар
2) Как клиент онлайн магазина, Я хочу использовать номер телефона, Чтобы залогиниться в системе
3) Как клиент онлайн магазина, Я хочу просмотреть описание товара, Чтобы посмотреть информацию о товаре

Each of TASKSin a similar spelling, is USER HISTORY. In this case, each of the orange stickers represents an Epic (that is, a large task that consists of a number of stories). To be absolutely precise, orange tickets are Epic in JIRA, task tickets are User Story in JIRA. Each User Story in JIRA can then be divided into several tickets, within which the developer implements certain parts of the feature.

Planning

It's time to talk about the last element USER STORY MAPSnamely about planning.

If the horizontal plane displays the time scale, then the vertical plane in this method displays priority. The higher TASK in the column, the higher its priority and, accordingly, the faster it will be executed by the developer.

There are two ways of planning in this method. Block with TASKS can be divided using horizontal lines into:

• importance or

• releases

In the case of importance, three levels are usually used: Must, Should, Could. The first means that tasks are of primary importance and means that they must be completed. The second is that tasks are important and it would be good to complete them. The third is optional and may not be performed. An example of division by importance is as follows:

As you can see in the screenshot above, we simply divided the set TASKS into blocks, relative to their importance.

The second way, instead of importance, is to divide it into releases. As follows:

As you can see, it looks approximately the same as the option above, however, regarding the link to the version number of the software solution, we can plan USER STORIES for release in certain versions of our software.

Modeling process

In conclusion, I will tell you how, in the opinion of the author of the methodology, the process of modeling maps should take place.

First of all, such maps are created not by one person, but by a group of people, including business-oriented people (Product Owner, for example), people interested in the feature and developers. Map modeling takes place in a workshop format, that is, live communication with discussions and colorful stickers on flipcharts and walls.

There are five main steps during the workshop:

1. Definition of scope. At this stage, all participants in the map modeling session should have a common understanding of what will be discussed. The users and features for which modeling will be carried out must be agreed upon in advance.

2. Creating a big picture. At this stage, basic ideas about the composition of the story are sketched out. The initial creation of the feature framework takes place.

3. Detailing. At this stage, through collective discussion, the elements of the framework are broken down into smaller tasks. The elements of the framework are reviewed, their places are changed, new ones are added, unnecessary ones are removed, and activities are highlighted.

4. Division into releases. At this stage, tasks are grouped into releases. Each release is actually a small MVP. Each release should have a description of the value it will deliver and a description of the metrics that can be used to measure the achievement of the release's goal.

5. Development and release strategy. At this stage, development tasks are already planned. If necessary, the map is updated again. The goal of this stage is to link planning on the map directly to feature development.

Glossary of terms

• USER STORY MAP – aka User Story Mapping; method of visual description and planning of tasks.

• USER HISTORY – aka User Story; is a way of describing a user's interaction with a software system in a narrative format.

• FRAME – aka Backbone; basic set of steps USER HISTORY.

• ACTIVITIES is a group of tasks that have similar goals.

Additional materials

The original of this article, as well as many others on various topics about IT and development, can be found on my website #fullstackguy.