A Beginners Guide to 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.
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”.
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.
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.
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.
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.
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.
