What Is User Story Mapping?

User stories are concise descriptions of a software capability, written from the point of view of the customer or end user. A user story is an efficient way of precisely capturing the ‘who’, ‘what’ and ‘why’ of a product requirement and can be thought of as a ‘to-do’ list that guides the product development journey.

In this article, we will talk about what is user story mapping, why it is important, and how and when it should be done. You will get a high-level view of story mapping, understand the core concepts involved, and learn how to bring user stories to life in your Agile projects so that your team can get the maximum benefit from this technique.

User story maps are simple, lightweight representations of the product development journey in an Agile project. This method was popularised by Jeff Patton who first wrote about it in his book User Story Mapping, where he outlined how this technique could be used to help keep the focus on user needs without getting tangled up in never-ending product feature requirements.

These story maps—which are changeable and keep evolving throughout the journey—enable the team to have meaningful conversations about user needs through the development process, never losing sight of the big picture.

Source: nngroup.com

User story mapping can be defined as an exercise during which product managers and development teams list out the work that will create the most value to end users, maximising customer delight.

During this exercise, teams create a dynamic outline of the ways in which the customer is expected to use the product. They try to understand which steps offer the most value and prioritise the stories accordingly. 

The user story format is an amazingly simple, concise sentence which clearly captures the requirements:

“As a [type of user], I want to [action] so that [benefit]. “ 

Without getting into too much detail, this format holds the essence of product interactions from a user’s perspective.

In the user-story map, all the activities are captured as short phrases that represent actual user actions. The first half of the user-story format, therefore, talks about what the user wants to do with the product. Next, the story is elaborated to include the key benefits as the second half of the conversation. So, this mapping method is called user-story mapping because it is cantered on the user and his or her needs. 

Later, the team fleshes out this simple sentence into detailed user stories that are discussed, with acceptance criteria added on, and then added to the product/sprint backlog for completion during each sprint as per priority. 

As we can see, the purpose behind user stories is to spark a dialogue around the solutions to user needs, from the viewpoint of the customer who will be using the product. The users are usually laypersons who are likely to be non-technical, and therefore the product must be easy to use, with an interface that is not complex and can be navigated easily. When the entire exercise is cantered on the user, the focus gets shifted to the customer’s perspective and maximises the product value in terms of user satisfaction. 

The user story map is created as one of the first exercises in the product development process. It is not a rigid document, and evolves as the journey unfolds, in keeping with the spirit of Agile.  

Subsequently, the user story mapping can be carried out whenever the team needs more clarity on how to improve on the first version, how to manage the backlog or when branching out in a new direction with requirements for product extensions. 

These are the processes involved in creating a User Story Map: 

Start by identifying the big picture. What are the broad user applications that your product must support? Draft these big stories on cards and arrange them in the order of priority for the end user.

Each of these big user activities is now broken down into smaller user tasks. Once again, keep the user in mind and prioritise these tasks from the user’s perspective. This is now the backbone of your User Story Map.

It helps to walk through the map with your customers or stakeholders. Is there anything you’ve missed out? They will help you to fill in the gaps.

Remember, at this stage it is still a high-level map and is highly likely to get changed down the line. Put the user tasks and subtasks within each activity into the order of importance.

From all the tasks listed, choose the ones that will go into your first version, which will be the MVP or Minimum Viable Product for your very first release.

Once you have the ball rolling, get started on your first release and then keep the momentum alive by planning subsequent releases in the same way. As you go along, you will be re-ordering the user story map, aligning subsequent stories horizontally to match your timeline, and creating order out of chaos.

As we have already seen, user story mapping is a systematic and highly efficient way of working out task priorities. When done right, it offers significant benefits that help teams build products that customers will love. 

Any product must be built with the end user in mind. User story mapping shines the spotlight on the user’s needs and tells the story from the point of view of the user. It maps out the user experience and helps to emphasize the efforts that will lead to the best outcomes, creating an outside-in approach rather than the traditional inside-out way of working. 

By breaking down the bigger picture into smaller tasks, while always keeping the vision in mind, teams can decide what is important and what needs to get built first. A holistic visualisation of tasks helps to put priorities in the right perspective. Teams will organize releases around the delivery of maximum value and push items of lower value to the bottom of the backlog. 

When requirements are laid out in the form of strong user stories, teams get clarity on what needs to be done. They can get a visual representation of how the larger work items can get broken down into smaller tasks and understand which are the tasks that club together to make one feature. 

Work gets grouped together into iterations, and releases are planned around delivery of value. By working on the more important tasks faster, teams can deliver product increments more rapidly, get feedback early and maximise customer value. 

Risks and dependencies get exposed early in the development journey, and developers can plan to mitigate these risks and iron out potential obstacles to smooth progress of work. Early planning can reduce dependencies and streamline the tasks more effectively. 

In the end, the project progress will depend on how well the team works together. User story mapping is a team building exercise where the team members get a shared view of the customer experience and work together to map out tasks. Team collaboration is built through meaningful conversations.  

User story mapping is one of the most important exercises during the planning stage. It brings cross functional teams into better alignment and helps them work collaboratively toward building the best possible product in the market. It is important that all teams whose work will contribute toward successful delivery should participate in the dialogue.

Team members from Engineering, UX/design, Product management, Sales, Customer support, Finance, Ops / IT, Legal and Marketing teams can take part in this exercise and give their valuable inputs. 

Teams can use planning software like Lucid chart, or even simple physical resources like a chart or a section of wall with sticky notes, to build the story map. Once they have decided on the medium to use, they can work on the following steps:

What is the problem that is solved by your product? This is your product goal, and it’s important to clearly define it at the outset. Once the goal is defined, the work that is to be done to achieve this goal can be mapped.

Any user story exercise starts with creating a persona as the end user. There could be several distinct categories of users, and all must be discussed. Each target persona will have a unique way of interacting with your product. Once the personas are understood, the user stories can be built from the perspective of each of these target users. This is an important aspect, as efforts are not wasted in building features that may not be important to any of these end users.  

Source: storiesonboard.com

Each user will use the product through a series of activities related to the product. Also known as themes, these activities are what will form the structural outline of the user story map. As an example, when buying an online service, users may wish to search a list of service providers, view their online rankings, check prices, and then put the chosen service item into the cart and complete the payment. These will comprise the main stories, and each will then be broken down into smaller tasks.

Each of the major stories is then fleshed out into smaller activities, which are then written down in the format: ‘As a _______, I want to _________, so that _______.’ 

For instance, this could be something like: As a subscriber of Amazon music, I want to search for hip-hop music, so that I can make a playlist. 

Once your bigger themes and user stories are mapped out, the next step is to prioritise and set the flow. Always rank them in such a way that the most urgent tasks are on the top of the list. The flow of tasks is usually always from left to right, and top to down. The visual representation of the user story mapping is already taking a visual form, helping teams to decide on the sequence and importance of work to be done.

This is a crucial step that will help to identify any bottlenecks that could impede progress. For instance, for task C to be completed, task A must first be finished. But for task C to even begin, there might be an interim task B that has not even been listed on the chart. In this way, all the missing gaps can be filled, and dependencies noted. Teams could also discuss workarounds if any if a dependency is found for which they do not have a resource now.

This is the stage where teams create action plans and schedules. Now that they know the quantum of work that is needed, they can gauge the work that is needed to deliver the most value in the shortest time and group activities together into sprints and releases, always keeping user priorities in the forefront.

While user story mapping can yield great results when done the right way, it comes with its own set of challenges for teams that are inadequately prepared. Look out for these challenges:

There might be instances where there is lack of clarity on who the end user is. In such cases, imagine a persona who represents the most possible end user, and work with this characterisation. 

The product goal is the solution to a problem that exists and is the reason for building the product. When there is lack of clarity on the problem itself, then the team could end up building stories on the wrong goals. This will waste time, money and effort and could result in some unnecessary rework and lack of motivation. 

Smaller teams who are co-located might find it makes sense to do their planning using sticky notes on a wall, or markers on a whiteboard. What happens if someone cleans the whiteboard by mistake, or some of the notes fall off and are swept away? All the planning would have been in vain! 

The stories in a user story map might need to be rewritten in the form of a product backlog, which involves some rework. Instead, use collaborative tools that map progress and automatically keep records of the work done. An added advantage of using the right tools is that distributed teams can also participate in the planning and tracking of goals. 

Once the user story mapping exercise is completed, teams will schedule their list of stories as per priority into sprints and releases. This forms the outline of the product roadmap, which will need to be shared with management and other teams that did not participate to ensure consensus. At this point, any teams which were not able to participate in the planning so far may give their inputs as well. 

The final user story mapping could be transferred to a shared software tool so that it can be viewed by all teams concerned in real time. Engineering team members will add technical specs and detail out their acceptance criteria, so that the Definition of Done for each story is known to all teams. 

This story map is never static but is always a work in progress. Estimates could be revised, schedules may be moved up or down, and parallel branches of the product might need to be added. At any time, the story map reflects the work to be done.

Story mapping is an especially useful and productive tool that helps product managers and development teams to maximise customer value through an adaptive, iterative approach. At each stage, they will find plenty of opportunities to learn and improve themselves and the processes. 

As such, story mapping supports these values of the Agile Manifesto:  

While user-story mapping and customer-journey mapping sound remarkably similar, there is a subtle difference in the emphasis. A customer journey map takes the perspective of the user and shows their interactions with the product and the steps taken to achieve an objective. It will also think about the user’s thoughts and experiences during this journey. 

On the other hand, a user story is mapped from the point of view of the product, as the user interacts with it. It will guide the planning of features and functionality, as the product tries to solve the user’s problems.  

Both will work very well when combined to achieve all the product goals and create and maximise customer delight. 

Story mapping solves the problems that arise due to lack of clarity in defining the requirements and tasks. It helps teams to comprehend user needs, set priorities for tasks, and collaborate with each other effectively. It helps to keep the focus on what is important- the end goals- so that the team does not get side-tracked into doing less important tasks. Once the user stories are mapped, the final set of acceptance criteria can be drawn up, schedules can be created, and a roadmap can be outlined.

User story maps give all the inputs needed to create a product roadmap. All the features are listed out in detail, broken down into user stories and basic priorities are set. All that remains is to group the features that deliver maximum value in the quickest time together, and schedule releases based on the team’s capabilities.  

Here is how to go about this: 

Conclusion 

Anyone who has created user stories knows that this takes time and effort, and the best results come with experience. They allow teams to see the bigger picture, keeping the user at the core of all development progress. When done the right way, user story mapping promotes meaningful collaboration, enables quicker feedback and faster deliveries, and results in creating high-quality product features that most suit customer needs. 

Research & References of What Is User Story Mapping?|A&C Accounting And Tax Services
Source

Share on Facebook

Tweet

Follow us