What is User Story Mapping? : A Complete Guide with Best Practices

Last updated on 29th Dec 2021, Blog, General

(5.0) | 19248 Ratings 1069

Share:

User story mapping is a visual exercise that helps product managers and their development teams define the work that will create the most delightful user experience. It is used to improve teams’ understanding of their customers and to prioritize work.

• What is User Story Mapping?
• What’s the Purpose of Story Mapping?
• What Agile values and principles does story mapping support?
• Who Created Story Mapping?
• Why Use Story Mapping? – What Problems Does Story Mapping Solve?
• What (Other) Benefits Do You Get Out of Story Mapping?
• Pitfalls and Mistakes
• How to Create a Story Map in 6 Steps (With Examples)?
• Using Story Mapping With Existing Applications
• Conclusion

What is User Story Mapping?

Story Mapping in Agile – What Is (User) Story Mapping?

Story mapping or user story mapping is a technique used in product discovery: the outline of a new product or a new feature for an existing product. The result is a story map: all user stories are organised into functional groups. It helps you keep an eye on the big picture while providing all the details of the entire application.

What’s the Purpose of Story Mapping?

The main purpose of story mapping is to prioritise product discovery and development tasks. You achieve this by placing user activities and tasks on a map that serves to put them in context. Story Map always shows how each individual story fits into the whole application. And that makes it easier to spot shortcomings and decide how important one is over the other.

What Agile values and principles does story mapping support?

Story Mapping supports two values of the Agile Manifesto. “Customer Support on Contract Negotiation” and “Responding to Changes when a Plan is Followed”. You get the best results when you collaborate with a (future) user or domain expert. Someone who is well acquainted with the work that your application has to support and the problems it needs to solve.

By using Story Mapping, it’s easy to respond to change. Because when you add a new user story, or you change or remove an existing one, it’s easy to figure out what else needs to be added, changed, or removed. User story mapping can be beneficial for teams that want to grow fast and create products that customers love, but it can also lead to disappointing results if the team is not prepared. Here are some challenges to watch:




No clear client– If you don’t know who the customer is, it’s impossible to find out how they experience the product. You need to know what you are mapping stories to.




No obvious problem– If you don’t know what problem your product is solving for customers, the whole exercise of user story mapping can be turned upside down. Building stories toward the wrong customer goal can be a waste of time and resources – not only in practice, but also for the sprints and releases based on it.




Limited utility– Physical story maps made from sticky notes on whiteboards are difficult to keep up to date. Notes stop being sticky and fall off, whiteboards get cleaned up and work is lost, or iterations and releases are shipped without updating the board. Additionally, story maps built in a single, physical location do not serve teams in other locations that cannot see them.




Rework and redundancy– Stories from a user story map typically need to be rebuilt into a flat backlog later, such as a software engineering tool, so that development teams can start working on them. As a result, this practice can make teams feel like they are doing the same thing twice.

Who Created Story Mapping?

• Jeff Patton first described Story Mapping in his “It’s All in How You Slice It” article in 2005, when he had already been using it for a few years. But then he didn’t call it story mapping. He coined that term in his 2008 article “The New User Story Backlog is a Map”. He even wrote a book about it: “User Story Mapping: Discover the Whole Story, Build the Right Product”


• At the end of the user story mapping exercise, teams will need to schedule their outline of priority stories into sprints and releases, if they have not already done so. The Product Team may wish to share or review the User Story Map with non-participating teams, including the Product Team Leadership, to ensure agreement on the Product Roadmap. Any teams contributing to an upcoming sprint or release that were not represented in the mapping exercise must also add their own work.


• Product and development teams will likely move their user story mapping artefacts to a shared software engineering tool. Engineering teams may need to add technical specifications and acceptance criteria to ensure user value is identified in the story mapping exercise.


• A user story map does not need to be static. Teams can update this with findings from research spikes, revised estimates, and user feedback from sprints and releases. Story maps can also be used as a visual roadmap to communicate both the planned work and the remaining work.


• Finally, teams doing user story mapping should take advantage of each exercise as an opportunity to get closer to customers and increase their level of empathy for what the customer is trying to accomplish. Story mapping is a tool to help product managers and their teams create customer value with an incremental, iterative approach, providing opportunities to learn and improve.

Why Use Story Mapping? – What Problems Does Story Mapping Solve?

When you’ve completed your product search, you’ll likely put the user stories in the backlog of the Scrum or Kanban board. It’s okay to run the development effort once you’ve decided on the build order.




However, the backlog management capabilities of these tools fall short for product and release management. Simply because the backlog is shown as a long, flat list. The filtering, labelling, and colouring you can do helps a little, but you never get the full picture. Story Mapping solves this by organising user stories in a simple helper layout.

What (Other) Benefits Do You Get Out of Story Mapping?

• Story mapping provides you with many direct and indirect benefits.
• Everyone can easily understand the whole application – usually the hardest part of software development. The Story Map outlines what your application solves and how it does it for anyone who may be interested in it. Everyone can take part in making it.
• You see the big picture of your application as a whole—losing the big picture is a common complaint among agile teams.
• Putting together and having the story map visible encourages repetition and incremental development.
• keeping the big picture at your fingertips
• Shows you where a user story fits into the whole system at a glance.
• Helps you decide what to make first. Story Map makes it easy to pick and choose user stories from a variety of features that together will provide meaningful value.
• This means that you can confidently determine and build an MVP or scope of a useful release.
• This means you can easily avoid creating something that doesn’t work. You won’t get lost or forget important parts that would make it effectively unusable, like a car without brakes. For example, because you delayed the low-value stories on which your high-value stories depend.
• Lets you walk the story map to test it for gaps: more easily spot where something’s missing.
• Allows you to make priority decisions taking into account the context of the system as a whole.
• This means that you will avoid blinding yourself to a single user story.
• When you create a physical story map, you get a few more benefits.
• The map becomes a focal point for collaboration and helps in shared understanding.
• The complete context provided by the map helps to quickly shape user stories relative to each other.
• You can add little stickies to user story cards to add additional information or mark up stories for the current and next iteration.

Pitfalls and Mistakes:

The most important pitfalls and mistakes with Story Mapping are:

Working without a client or someone well acquainted with their work

You need to collaborate with anyone who uses or will use your product to support their work. Without their input and perspective, you may be under-estimating what’s important and what will provide real value. You’ll be playing a hit and miss game and possibly ruining the development effort.




No goals, no problems to solve

Working without a problem to solve, a goal to reach, you have nothing to guide your decisions and you won’t know when you’re done. Leading to a vain effort, or at least an attempt at something at the wrong time.




Map not visible

Out of sight, out of mind. Without a Story Map as a visible reminder of the bigger picture of your application, it’s all too easy to turn off course. As in danger of getting lost in the weeds: getting caught up in the details of a single story that are irrelevant to the whole. It hurts even more, when those details try to outweigh the value of the story’s merits. While a physical story map is preferable for the added benefits it provides, with so many remote teams nowadays, you won’t always have that luxury. But you can still keep it highly visible. For example you can have a dedicated, large monitor that can show a map of every place you have team members.

How to Create a Story Map in 6 Steps (With Examples)?

1. Start with the Big Boulder

• Identify the larger stories, wider user activities that your application needs to support. They are big stories because they have many steps. These steps do not require any specific sequence or workflow. In fact, many user activities have steps that a user will perform at different times and on different schedules.
• Write each activity on a card. Arrange them in the order that makes sense to the user. If one speaks of doing one activity and then another, arrange them in that order. If the activities are not performed one after the other, just use the sequence the user talks about. This will help tell the story of the application to others.
• Let’s say you’re building a fun event club site. Visitors can look for fun events to attend. Members can join and host events. And the team behind the site acts as a moderator and checks whether new events are within the guidelines.



2 Your Boulders Open

• Break down each user activity story into short stories, user tasks. Place the user’s actions under the activity to which they are related and arrange them in the same direction as the activities and in the order that makes sense to the user. Now you have what is called the backbone of your Story Map.
• Most user tasks have their own steps or independent subtasks. You put these subtasks under the user task (if you were going horizontally) to which they belong. Both user tasks and subtasks become user stories that you implement. Eventually, the user needs to select an event from a list to view its details or join it immediately.



Develop Your Skills with Advanced Agile Certification Training
Weekday / Weekend BatchesSee Batch Details

3. Find the Pebbles That Gone Away

• Follow someone else on the map from start to finish. This can be a user, a developer, a tester, or any other person with a stake in the application.
• Talk about the user(s) of your application and how they are using your application. This is a kind of rubber duck debugging for your story map. And it will quite naturally bring up the things you have missed. Either because you think of them yourself, or because your partner points them out.
• When you’re walking the map with someone, take the opportunity to annotate the story map with other information. Pain points in the current system, opportunities that the user awaits. Edge cases and constraints you need to take into account. Write them on a stick and stick them on the respective card.



4. Put Your Pebbles in Line

• There is no sense in prioritising user activities. Aside from activities that will not be used on a daily basis, there is a high probability that something from each activity is needed to form a working whole.
• So focus on prioritising user tasks and subtasks within each activity. The added benefit is that you don’t have to think about the relative importance of tasks related to different activities.
• In our Fun Events Club example, the subtasks are already in order of importance. A little premature optimization by your author.



5. Carve a Valuable First Boulder Out of Your Pebble Pile

• Select the tasks from each activity that are needed to create the first version that works from start to finish, even if it’s still in a very rudimentary way. That is your MVP, your Minimum Viable Product.



6. Continue Sculpting

• Plan your upcoming release by prioritising the remaining tasks. It is completely up to you how you want to proceed.
• You can choose to prioritise stories with the highest value from many or all user activities. You can also choose to focus on a single activity and prioritise all except the least valuable stories. And businessmen in your company may want to take other aspects into account. They are in the best position to decide which features and stories to make a good release.
• Instead of drawing lines between stories to mark which ones go into a later release, you can also rearrange the map to show the release as a horizontal extension of the stories.

Using Story Mapping With Existing Applications:

• Story mapping isn’t just for new applications. You can also use it for existing applications.
• To help you understand what an application does and recreate the big picture of it so you can take advantage of it as you move forward.
• And of course to map out new features and place them in the context of an existing application.
• If you cannot (not allow) to create a complete story map of the existing application first, then at least place all existing user activity.
• This will give you references for the new features.
• And it will also give you a place to put the tasks you need to add or change to existing user activities. For example, when you create a new feature for sending targeted emails. You have to select multiple contacts in the existing contact list. And you’ll probably have to add some additional filtering capabilities in there as well.

Who should participate in user story mapping?

User Story Mapping is a collaborative exercise that helps align cross-functional teams to build a product that will be a better tomorrow than it is today. For this reason, any team should be represented whose work will contribute to the successful delivery of customer value. Since a user story map creates a holistic view of the product, it is helpful to include any team members responsible for crafting the entire product experience. These teams are often represented in user story mapping exercises:



• Engineering
• UX / Design
• product management
• sales
• Marketing
• customer support
• Operations / IT
• finance
• legal



User story mapping begins with the decision of what medium to use to create the story map. This can be done with simple physical resources – such as a wall or whiteboard and sticky notes – or with a variety of software tools that are available for creating virtual maps. Virtual planning can be helpful for distributed teams. Whatever the medium, teams will want to take the following steps:

Frame the problem

What problem does your product solve for customers, or what does it help them with? It’s important to take a goal-first approach to mapping the work ahead, and teams need to make sure they’re mapping out the customer’s goal. This is true even if teams are improving an existing product. User story format (As a [user type], I like to [action] so [benefit].) It can be helpful to think about product interactions from the user’s point of view.




Understand the users of the product

Who is the target audience for your product? More than one is likely. Different audiences may have different goals and ways of interacting with your product. Starting this exercise with a group of user individuals can ensure that teams share an understanding of the target audience and build stories from that perspective. It also eliminates wasted effort on edge cases that are not suitable for your target audience.




Map user activities

All users who interact with a product are likely to do so through a series of common activities. These activities – also known as themes or functions – form the backbone of the user story map. For example, users of an ecommerce product may want to find items for sale, view items by category, place the item in a shopping cart, and complete a purchase. These activities will include stories at the top of the map, which the team will then split into smaller user stories.




Map user stories under activities

With the backbone and key themes defined, the team can now build the skeleton of the map by breaking each activity or theme into smaller user stories. For example, under Shopping Cart Activity, there might be stories like “As a buyer, I want to edit and delete items in my cart so I can change my mind before making a purchase.”




Flow and priority

With high-level themes and detailed user stories, the next step is to prioritise stories, ranking them vertically so that the most important are at the top. Then, Teams maps how users flow through the product – usually from left to right. If a product has multiple types of users, teams might want to map out different scenarios for each. These actions help teams decide which stories are important and which are less important to deliver an enjoyable product experience for the target audience.




Identify gaps, dependencies, technical requirements and options

The story map gives teams the ability to visualise potential issues that could slow them down later, such as bottlenecks, dependencies, technical architecture, or missing information and capabilities. Identifying these risks before design or development work begins can help teams identify and mitigate them, increase usability, and come up with alternative solutions.




Sprint and release planning

This is where the team turns visual exercises into executable work. With stories prioritised from top to bottom, teams can look at the work that will deliver the most value in the shortest amount of time and group these stories into development sprints and product releases. Teams will create horizontal “slices” on the map, grouping stories by priority within each significant user activity. It is important to consider that it is not just about identifying what is required for a minimum viable product; Instead, it’s important to identify the most important task that needs to be accomplished in order to create a delightful customer experience.

Conclusion:

• Story mapping is a visual exercise that helps product managers and their development teams define the task that will create the most enjoyable user experience. It is used to improve teams’ understanding of their customers and to prioritise work. Software leader Jeff Patton is often credited with developing and sharing extensive knowledge about user story mapping.


• In user story mapping, the team creates a dynamic outline of a representative user’s interaction with the product, evaluates which steps have the most benefit for the user, and prioritises what needs to be built next. For agile organisations, it provides the option of creating a flat list of backlog items or working from lengthy requirements documents.


• User story mapping employs the concept of user stories – which communicate requirements from a user value standpoint – to validate and build on a shared understanding of the steps for a product users love. Teams write user stories in a format that captures business value and can be completed within a development iteration (commonly called a sprint). User Story Format – As a [user type], I want to [action] so [benefit]. — It can be helpful to think about product interactions from the user’s perspective.