The traditional way of bridging the gap from the vision of a product to defining what it should include and how it should work often implied relying on the lengthy, expansive, and sluggish business requirements documents and functional design specifications.
The distributed documentation and the information laid out inside often took place of a more dynamic work process which would include ongoing conversations about ideas, problems, solutions, and users and their needs.
Because of this, projects exclusively relying on these documents often ended in failure. Hardly anyone has the time or enough attention to read through them from beginning to end. Even those who do read them would commonly come away with vastly different ideas about what the product would be and what it should do.
Instead of supporting and enhancing productivity, these heavy documents would do exactly the opposite. They would stifle the key elements of the successful development process, such as creativity, collaboration, communication, innovation, and free flow of ideas.
The use of user story mapping as an approach to requirements gathering offers an alternative to traditional methods and shows that things could be done differently. It shows that lightweight representations usually work much better.
Instead of writing long and wasteful documents, user story mapping provides an effective tool for capturing requirements during inception through an engaging activity where everyone involved in the product development can take part.
Table of Contents
What is User Story Mapping?
A user story mapping session exercise in which teams visualise a user’s journey through a product and outline interactions the user is expected to have with that product. It’s mainly used in agile environments and serves product managers and their teams to specify the work that will result in creating the most enjoyable user experience. With the help of the visual nature of user story mapping, everyone involved in a project can gain a better understanding of potential customers and prioritise work tasks.
When designing user story maps, the development team creates an overview of expected user interactions with the product, and based on that, assesses the essential steps that will benefit the potential customer the most.
Also, teams use the user story mapping outline to determine the order of steps in the development process and decide what should be built next. In the process, they’re able to distinguish between the features that are just nice additions to the product from those that are absolutely necessary.
Through the user story map, product managers and their teams can break down each requirement and create a visual representation of how each piece interacts with another. Plus, mapping makes it easier to identify and expose potential hurdles that can impact successful product delivery.
The foundation for the user story mapping approach is the concept of user stories, which express requirements based on user value. The mapping process uses these stories to validate the steps needed to create the product that the customer will enjoy and also to ensure that everyone involved understands those steps.
While it doesn’t look like the actual map, the user story map still shows how the tasks and steps related to user stories naturally progress. Commonly, the map is created using either physical sticky notes or digital cards and ranges them on the whiteboard in a table or panel format.
Who Invented User Story Mapping ?
Who invented user story mapping? Jeff Patton
is responsible for the idea of user story mapping. The goal of the user story mapping exercise for Jeff Patton was to guarantee that a product delivered on the requirements of the end-user — both by prioritising the most essential features and bringing together the team in one common vision.
Jeff Paton wrote the book User Story Mapping: Discover the Whole Story, Build the Right Product which provides background to the approach and guidance to apply.
How to Map a User Story?
User story maps can be built at any point during product development, whenever there’s need to align the team and drive the discussion to solve certain problems. They can be created to depict the experience of a new product, after completing the initial discovery work, or even for a product that already exists, after the usability testing.
In all these cases, a story map should illustrate the solution to the problems uncovered during the research. Teams will usually maintain the finished map, occasionally revisit it, and add modifications to reflect the current state of the product.
Building a solid user story map may take time, but the process itself is rather clear and logical. The mapping process itself is particularly valuable as it offers an opportunity to interact and have discussions with other team members. Once the session is finished, everyone involved should come out of it with a better understanding of the product’s vision and the ways it will help the users.
The user story map lays out three different types of actions to a different levels of detail. They range from the most general action, or activities, to the most specific, or details, with steps in the middle of those two. User activities and steps are lined up horizontally, across the top of the map, while the details are stacked under corresponding steps and arranged according to the level of priority.
Of course, the first thing to do when mapping a user story is to decide on what medium to use. Mapping can be done with simple and easily available physical resources, such as sticky notes, and a whiteboard or a wall. Also, the team can create a virtual map, using one of the many available software tools. Whatever the medium, the mapping process should include several crucial steps.
If you are a beginner at doing user story mapping you may wish to pair up with someone who is more familiar with user story mapping. Mike Cohn covers user story mapping very well in his user story mapping course.
Framing the Problem
To build a proper user story map, it’s necessary to first identify what problem is the product supposed to solve for the users or what it’s supposed to help them do. Framing the exercise around the common goal is essential for all the work that will follow and the team needs to make sure to properly map the customer’s goal.
To do this right, members of the team should discuss what problem they’re trying to solve, who they’re building it for, and why is the company building that particular product or feature. This is crucial even if the team is only updating or modifying the current product.
Understanding the Potential Product Users
The product may have more than one target audience. Each potential audience group could have different goals and interact with the product in a different way. However, identifying the primary audience will likely keep development on track and help develop a successful product.
That’s why it’s necessary to start the exercise with the set of user personas as it helps members of the team gain a shared understanding of their potential customer base and build stories based on that perspective.
Furthermore, this approach will eliminate any fringe groups and edge cases that don’t fit with the primary target audience. To gain some insight into how users interact with the product, the team may use focus groups or A/B tests.
Mapping User Activities
Every interaction with the product will come in some form of common user activities. These user activities, sometimes referred to as functions or themes, are an anchor point or the backbone for creating the story map.
These activities should be fairly broad as they will comprise the stories across the top of the map. These will then be broken down into smaller, more specific user stories to make up the action behind each activity.
Mapping User Stories Under Activities
Once the backbone and the major themes of a story map are set, it’s time to fill out the map skeleton and create a larger customer journey by breaking down each activity into smaller stories. For example, if a product is a video streaming website, the user activity may be choosing a video. Under that activity, there will be smaller user stories, such as searching for a video or filtering the search results.
Flow and Prioritisation
When the main themes of the map and the smaller-scale user stories have been identified, the next step is to establish a hierarchy and prioritise those stories. They should be ranked vertically in the order of importance, with those of higher priority on top.
This will help team members understand which stories will have the biggest impact on the customer journey. After this, the team should define how the users will flow through the product, commonly from left to right. In case there are multiple users for the same product, the map should include different scenarios for each of them.
Identifying Roadblocks
The process of product development will surely face some hurdles along the way, The story map should enable teams to identify upfront the issues that can later slow down the entire project. There are a number of these potential issues, including missing information, bottlenecks, technical architecture, dependencies, and anything else that may cause the production to slow down.
With story maps set properly, team members can spot these problems before the work on design or development even begins. That way, they mitigate and minimise those risks, improve usability, and create alternative solutions.
Planning the Sprint and Releases
The final step of building a user story map is turning the visual representation into executable work. This is when all the mapping comes to fruition. With user activities and stories properly prioritised from the top down, team members can batch them into sprints and product releases in away that will deliver the most value in the shortest time.
Within each user activity, the team will create horizontal slices, grouping the story by priority. In this stage, each piece of the user story map will be assigned to a particular member of the production team, along with a precise explanation of how to complete it. The most important thing here is not to identify what is required for the MVP (minimum viable product), but, rather, to identify the most important work processes to be completed in order to provide customers with an enjoyable experience using the product.
What are the Benefits of User Story Mapping?
Using User story maps as a visual blueprint to depict the customer journey through a product brings multiple benefits to the product development process and significantly contributes to successful product release. Below are some of the most important benefits that can be achieved through user story mapping.
- Creating Shared Understanding – Getting everyone on the same page and working towards the common goal is the key to smooth and successful product development. During the process of user story mapping, team members discuss the most important aspects of the project, including ideas, product features, user experience, and potential problems. These discussions provide the foundation for building shared understanding and a story map is used to facilitate those discussions. The mapping process also brings together different shareholders that wouldn’t interact otherwise.
- Putting the User First – One of the most important features of user story maps is that they look at the product from the user’s point of view. This allows product team members to set clear priorities and distinguish “nice-to-have” features from those that truly bring value to customers. Ultimately, user story mapping helps develop a product that will benefit the customers the most.
- Providing Direction for the Whole Production Process – Besides helping us determine where to start, user story maps also provide guidelines the production team can follow right up until MVP and any subsequent iterations and sprints. User story mapping also helps uncover any holes in the existing user flow and product requirements. Plus, it identifies any information architecture problems that can disrupt the development process later on. This helps members of the team address these problems early and minimise the potential damage.
- Encouraging Shorter Release Cycles and Smaller Releases – By slicing out releases, the story map helps us understand how big or small the releases actually are. So, it’s a great instrument for cutting down release time and faster iterations. Story map provides a great platform for asking questions such as if something is really necessary for the product to bring value to customers or can a certain release be broken down into two or three smaller ones.
- Onboarding New Members of the Team – Every time someone new joins the team, it’s important to have an opportunity to explain a product to them in a clear, fast, and productive way. They should be aware of enough details to help the team fill the gaps, but still not overwhelm them. A story map is just the perfect instrument for doing this. It also helps the new team member understand the current point in the process as they can just refer to the releases on the map.
User Story Mapping Tools
There are a number of tools in the market place that can aid you with user story mapping. Which one you choose will depend upon your context and your organisational ecosystem for ways of working.
User Story Mapping Tool – Using Miro
Miro provides user story mapping templates for you to visualise your consumer journey and improve your products and bring a user-centric approach.
The Miro collaborative tool has been used my many organisations during the pandemic with the increase of people working remotely. Having the ability to do user story mapping in Miro is a useful benefit for those who are already using the tool.
User Story Mapping Tool – Using StoriesOnBoard
StoriesOnBoard provides a user story mapping tool that is simple to use, visual, intuitive, and a collaborative solution.
User Story Mapping Tool – Using LucidChart
LucidChart provides a user story mapping tool to pap your user’s journey through your product.
User Story Mapping Tool – Using Azure DevOps and SpecMap
If you are using the popular Azure DevOps toolset then you can take the opportunity to install and use SpecMap to do user story mapping.
The Azure DevOps SpecMap market place plugin is a user story mapping Azure DevOps tool for Azure Boards that allows you to build visual story maps from Azure DevOps work items and helps organise your development teams. Story maps provide a great basis for discussing the needs of your users, and prioritising development to deliver the biggest impact.
User Story Elaboration
User story mapping provides a good context for user story elaboration. Some techniques for user story elaboration includes:
- Slitting user stories into smaller stories where further details can be described.
- Including user acceptance criteria that provides sufficient details for the team to understand what is required from the user story. Sometimes these details may be added or refined during backlog refinement.
For user story elaboration it is important to focus on elements of the user story that provides a shared understanding to the team and the value that will be gained by completing the user story.
User Story Templates
Business Analysis Doctor has supporting user story templates and agile templates included in a business analysis template package including an user story and acceptance criteria builder template, story splitting checklist, daily standup checklist, iteration/ sprint review checklist, retrospective checklist.
