A Beginners Guide to Story Mapping

Stefan Döbrich
Ein Kurzer Leitfaden für die Durchführung von Story Mapping

A beginner’s guide to story mapping answers the questions many organizations ask about agile transitions. Where do our requirements come from? How should our teams be structured? In what form do we deliver our product and what value does it deliver to the customer? Story mapping can provide answers to all of these questions.

The Aims and Goals of Story Mapping

The goal of story mapping is to assign the requirements for the product, in the form of user stories, to the various releases of the product. For this purpose, the user stories are sorted and structured according to their belonging to tasks (epics) and activities (domains).

The result of a story mapping is a common view of all participants, with regard to the structure of the product, the priorities and order of implementation of the requirements, as well as the boundaries of the different domains. The product teams can then be established based on these boundaries.

A Simple Example

To explain and clarify how story mapping works, let’s choose a simple example. The product to be developed should allow a person to leave the house after getting up in the morning. Activities and tasks that someone carries out before leaving the house must be mapped. The user journey should therefore depict the actions that a user carries out after getting up until leaving the house.

Defining User Activities

The first step of story mapping is the identification of activities that the user can perform with the product to be defined. This is a classic task for the product owner. To do this, he can question stakeholders and potential users, draw on the knowledge of business analysts and of course also bring in his own creativity.

The activities describe user interaction at a very high level of abstraction. For example, a banking app could contain the activities “Manage Account” or “Manage Depot”. In our example, the activities “get out of bed”, “do personal hygiene”, “have breakfast” and “leave the home” are relevant contents.

a story map with several top level activities
Fig. 1 - A Story Map With Several Activities

User Tasks

In a second step, the identified activities are further refined. The focus is now on the tasks that are presented in the context of the individual activities. Refinement is also a task for the product owner, in consultation with stakeholders, potential users, sponsors and business analysts. The tasks are assigned to the individual activities on a subordinate level. This level is also known as the backbone of the story map.

The user journey can ideally be told as a path from left to right through the story map, and thus also through the backbone. Therefore, the task should be sorted so that it is put in a natural order. The sorting of activities can also change, bringing the intended user journey closer.

In our example, each activity was refined into three tasks. These describe the activities in greater detail. Performing these tasks in the correct order will deliver the desired value to the customer. In the example, the activity “Have breakfast” was divided into the tasks “listen to radio”, “drink coffee” and “eat cereals”.

a story map with several task for each activity
Fig. 2 - Tasks that belong to the activities

The defined tasks can be converted into epics by the product owner after the story mapping. These epics describe a complex, but ideally completed, task block in the sense of agile requirements engineering. The formulated epic then contains a detailed description of the intended functionality, customer added value and business value.

Refinement of User Tasks

After the tasks for the future product have been defined, it is now time to break them down even further. The product owner can already consult the development team for this. However, the Product Owner can also perform this task alone. The detailing of the tasks provides the individual steps that are necessary to process a task.

These sub-tasks can be converted into user stories after story mapping. The name of the procedure is derived from this. The user stories describe the actions to be carried out from the perspective of the respective user, and at the same time motivate why the task should be carried out.

a story map with several steps for each of the tasks
Fig. 3 - Steps to complete the tasks

In our example, the 12 defined tasks were broken down into a total of 42 sub-tasks. Since it is a very simple example, the number of tasks and sub-tasks is still manageable. In practice, it can easily happen that a large number of epics and several hundred user stories are derived from them. When carrying out the story mapping in an analog form, it is necessary to have enough space and material available.

Identification of Dependencies

In the fourth step it is necessary to identify any dependencies between the individual user stories. At this point at the latest, the product owner must involve the development team. The technical dependencies, between user stories can only be evaluated and resolved by the development team.

a story map with dependencies between processing steps
Fig. 4 - Exemplarische Abhängigkeiten zwischen den Schritten

Regardless of whether the requirements are recorded in analog or digital form, it is necessary to make the dependencies transparent. In the further course, these serve as input for determining the order of implementation of the various epics and user stories. A user story can only be implemented if all user stories on which it depends have already been successfully implemented and completed.

Prioritization of User Stories After the dependencies of the user stories have been identified, there is usually still freedom with regard to a possible order of implementation. In our example, this can be seen from the task of “making a bed”. It is not important whether you first shake the pillow or the blanket.

At this point, the product owner has the opportunity to incorporate the prioritization requests of stakeholders and users and to reorder the user stories taking their dependencies into account. It is important at this point that user stories that are dependent on each other remain in the correct order.

Cutting out an MVP

If the product owner and the development team agree that the illustrated user stories, epics and activities have been sufficiently refined and described, then the functional scope of the individual releases is derived from the story map in the last step.

The first release of a product should always be a minimum viable product. This is a product with the smallest, sensible, usable range of functions. All user stories that are required to deliver this range of functions are assigned to the MVP.

a story map with a defined MVP and subsequent releases
Fig. 5 - Definition of an MVP and following releases

In further steps, the product owner defines further releases, taking into account all external factors and the dependencies and priorities of the user stories. Feedback from the development team regarding technical aspects of implementation should also be taken into account.

In the example shown there is an MVP which includes “getting dressed”, “taking keys” and “leaving home”. It is no more than doing these tasks to leave the house after getting up. You can even discuss whether it is necessary to take the keys with you or if this cannot be part of the second release.

The image below visualizes the user journey along the MVP in a slightly different way. For this purpose, the activities are arranged optically linear, so that it is easier to see how the user moves from “left to right” along the user stories. All other releases will expand the user journey. This can be by extending the chain of actions, by introducing parallel branches and actions, or by establishing completely new tasks. However, nothing changes in the fact that the user journey can be represented as a sequence of actions along the story map.

a story map with the MVP as a straight sequence of activities
Fig. 6 - The MVP as a sequence of task steps along the activities

Identifying Your Domains and Shaping Your Teams

In the context of agile transitions, the question of the structure of the individual development teams often arises. Which functionality should be implemented by which team? Where are the boundaries of the functional blocks? What are the different products that integrate with each other and form the whole solution?

These questions can be answered intuitively using a story map. The defined activities represent individual domains in terms of the product structure. In our case, the activities could also be named after their location “bedroom”, “bathroom”, “kitchen” and “hallway”. These are the domains where the activities take place.

The teams should be structured so that they can fully implement and map a domain. It is also possible that a team is responsible for more than one domain. In this case, the domains should ideally be “adjacent”. In this way, clearly defined interfaces between the different domains can be established and the responsibilities for functions clearly assigned to the respective teams.

Final Thoughts

The story mapping should ideally be carried out in analog form, with the help of post-its. This allows a high degree of interaction between the participants, as well as a high dynamic regarding the structuring and decision making during the story mapping. Since a story map can become very large, you should take care when planning a story mapping to choose a location with sufficient free space on the walls.

Story mapping is an excellent technique for capturing requirements in agile teams, structuring them and transferring them into a release plan. The user journey can be visualized along the story map, and the structure of the cross-functional teams can be derived from the structure of the story map. The information obtained in this way creates a common view of all participants on the product and reduces the dependencies between teams.

Back to blog

Recent articles in the Agile Blog

Throughput und Delivery Rate in Kanban Systemen

Throughput and Delivery Rate in Kanban Systems

Although the terms throughput and delivery rate are often used interchangeably, there are subtle differences between them. This article explains the exact difference between throughput...
Lead Time und Cycle Time in Kanban Systemen

Lead Time and Cycle Time in Kanban Systems

When discussing Kanban systems, the terms "lead time" and "cycle time" often come up. However, different people use these terms differently and sometimes they are...
Ein kurzer Leitfaden über Objectives und Key Results

A Beginners Guide to Objectives and Key Results

Objectives and Key Results (OKRs) is a goal-setting framework that helps organisations set clear, measurable goals. This article shows the definition of OKRs as well...

Kanban Trainings at AgileSkills

Team Kanban Practitioner

Regular price €600,00 EUR
Regular price €700,00 EUR Sale price €600,00 EUR
Excl. VAT

Kanban Systems Improvements

Regular price €1.200,00 EUR
Regular price €1.500,00 EUR Sale price €1.200,00 EUR
Excl. VAT

Kanban System Design

Regular price €1.200,00 EUR
Regular price €1.500,00 EUR Sale price €1.200,00 EUR
Excl. VAT

You have open questions about agile methods?

If you still have questions about the article, about agile methods, or problems with the implementation of agility in practice, please write to me and we will arrange a non-binding initial meeting.

Let's discuss how I can help you on your way to more agility!

Dr.-Ing. Stefan Döbrich