What is User Story Mapping?

User story mapping definition

As the number of entries increases, backlogs become easily confusing. The visualisation with user story maps offers a remedy here, because they can be used to display connections that can easily be overlooked when working with one-dimensional backlogs. The user story map is a kind of map that shows the order in which a user applies the system on the one hand, and the assignment of user stories to the higher-level wishes of the users (i.e. to the epics or features) on the other.

Story mapping makes it easier for you to create a product backlog. The visual, structured structure makes it possible to

• create a common understanding,
• identify gaps in the backlog and
• identify dependencies.

In addition, it can also help with the allocation and release of planning activities.

Explanations:

In contrast to a flat product backlog, a user story map offers a two-dimensional map, which makes it easier to understand the relationships during development.

The horizontal arrangement of the high-level requirements (epics, themes or features) follows the sequence of system usage by the user. Simply put, the user first uses Feature 1, then Feature 2, and so on. This arrangement is called the backbone.

The user story map also provides a prioritisation. The higher a user story is arranged, the more important it is.

When are which user stories implemented? You can recognise this information by its assignment to sprints.

Types of user story mappings

There are different types of mappings with different forms of arrangement. For example, you can display product visions and goals, necessary measures, derived tasks, and user stories. Or you can display epics, features, user stories and tasks in a common presentation. The illustration of non-functional requirements, functional requirements and user stories can also be found in companies. If you want to identify requirements from a user perspective, e.g. from the point of view of a customer, an employee, a partner etc., a visualisation with user, goals, workflow, actions and user stories would be appropriate.

Whether the visualisation of the items used is top-down, i.e. from top to bottom, or from left to right, is irrelevant for the application. It is important that you find abstraction levels for your development with which the participants can better identify requirements and understand existing relationships more easily.

User story mapping as an iterative process

Working with story maps provides a framework for discussions between teams, team members and stakeholders. Like the actual product, it continues to evolve. It is always a snapshot of the team’s thoughts. If new insights are gained, assumptions confirmed or refuted during the discussions, the story map changes accordingly.

User story mapping begins with the decision as to which medium should be used to build the story map. It can be done with simple physical resources – such as a wall or whiteboard and sticky notes – or with a variety of software tools that help create a virtual map for distributed teams. Regardless of the medium, story mapping consists of the following tasks:

• Definition of the target group(s)
• Definition of stakeholder objectives
• Visualisation of the backbone – the red thread (of the workflow or the history) – of the users
• Creation and assignment of user stories to the highlight requirements of the users
• Prioritisation of user stories
• Identification of dependencies, technical requirements and gaps
• Use of technical stories and spike stories to find alternatives and eliminate ambiguities
• The planning of sprints, releases and reviews

Experience shows that assumptions made at the outset should also be reviewed regularly. User goals can change, as can the prioritisation of user stories or the technical possibilities of architectures used.

Cooperation in a team

User story mapping is a collaborative approach that enables cross-functional teams to develop products and systems. It therefore makes sense for representatives from the teams who contribute to the realisation of customer value to participate in the mapping. Representatives from the following areas can do this:

• development and architecture
• IT and operations
• product management
• project manager
• UX design and conception
• sales and marketing
• finance and law

In addition, regular communication with stakeholders is always recommended.

Advantages of user story mapping

There are several advantages to working with user story maps:

• Items that are captured in a haptic format promote common understanding and teamwork.
• The backbone shows the highlights of customer requirements; it is a common thread and offers good orientation in the realisation of requirements.
• The visualisation provides a good overview of the scope of the requirements and tasks.
• Prioritisation is made easier because items can be moved easily. At the same time, the connection to customer requirements is maintained. User story mapping is therefore also a good tool for release planning.
• Mapping allows larger items to be divided into several smaller ones, with dependencies between them always remaining traceable.
• Dependencies can be easily represented so that special challenges or risks can be identified at an early stage.
• Working with user story maps is fun and promotes dialogue within a team, especially since it is also a tool for teams.

Sometimes criticism is voiced about user story mapping because the method does not promote exchange with customers. However, the criticism misses the core of the approach, because it is primarily a tool for development teams and not for communicating with customers. Unaffected by this, the product owner can communicate regularly with stakeholders and, depending on the situation and needs, communicate the insights gained. Similarly, there is the “disadvantage” that individuals may find it difficult to create a story map, as they rarely know all product and development related aspects. Precisely: it is a tool for teams.

Tips for user story mapping

There are situations where it makes sense to capture additional information in a story map. These could be technical stories or spike stories, links to personas or simple “nice-to-have” user stories. The right thing is what helps you in your situation. Here are some options:

• Use different colors to display different levels in the story map, such as orange for targets, blue for epics, green for features, and yellow for stories.
• Use threads or masking tape to highlight connections.
• Use stickers for additional information, follow-ups, notes or questions.
• Link additional information (drawings, graphics, documents) to increase common understanding.
• Build in alternatives to evaluate more robust or cost-effective solutions.

Critical points and additional tips

User story mapping is a very good tool for agile teams. As a tool, it can also cause problems if it does not fit your corporate culture or if your teams are poorly prepared for such cooperation. Here are some challenges you should be aware of:

• Who is your user and what are his goals?
  If you don’t know who the users of your solution are, it’s impossible to figure out how he’s going to experience the product.
• What is the problem to be solved?
  If you don’t know which problem your product solves for customers, the entire user story assignment can easily fail. Aligning user stories with a wrong customer goal can lead to a waste of time and resources – not only in mapping, but also later in the sprints and releases based on it.
• How is your story map updated?
  Physical story maps, consisting of sticky notes on a wall or whiteboard, are difficult to update. The notes fall off, whiteboards are cleaned and the work is lost. It also happens that releases are delivered without Story Map updates, i.e. planning and reality diverge.
• How do you guarantee access to the story map?
  User story maps created at a single physical location are often not available to teams at other locations. And even when used at a site with multiple teams, access to the information must always be guaranteed.
• How do you avoid rework and redundancy?
  Knowledge gained from working with a user story map often needs to be recreated or revised in a product backlog. This can give you the feeling that the same work is being done twice.

User story mapping tools

Organisations are often faced with the question of which tool to use for user story mapping. If there is a possibility that all participants come together in one place, the whiteboard in combination with Post It’s is generally considered the best solution. But what if digital solutions are needed because participants are distributed and remote? Here you will find some tools, but without rating and without claiming to be complete:

• aha
• Avion
• Cardboard
• craft
• delibr
• draft
• Miro
• Mural
• ScrumDesk
• StoriesOnBoard
• Trello
• upwave
• Visual Paradigm

Notes:

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

The current Scrum Guide 2020 does not mention user story mapping. But this is not surprising, because user stories are not mentioned there either. The guide “only” speaks of backlog items.

A recommendation for the practical use of User Story Maps can be found in the article: Boost your backlog.

Here you will find additional information from our Smartpedia section:

t2informatik develops and modernises software as a service provider. Click here to learn more.