Apply the User Story Mapping Technique to Product Development
In the area of Scrum software development and product management, in 2014 Jeff Patton proposed User Story Mapping as an agile technique to facilitate the construction of the product backlog and thus improve communication between teams and the understanding of a system.
In this article, Appvizer tells you how to implement this tool and how to use it to respond in an agile and fluid way to your customers' needs.
What is User Story Mapping
Definition of the user's history
To define the User Story Mapping, we must first start from the notion of the user story. This refers to the narrative or expectations of users regarding the product and their clear representation, based on information such as:
- identification,
- order of priority,
- estimation of the volume of work required,
- demonstration,
- additional observations.
User Story Mapping: goal
To carry out such representation, we speak of story mapping or tracing of the user's history. The expertise of the Product Owner and the information he has collected from his customers is organized and presented in a clearer way. For example:
"As a [type of user], I would like to have [this functionality] that I can benefit from [in this way].
How to build the User Story Mapping? → 5 steps
1. Delimitation of the problem
This first stage is fundamental since it is the moment when the team understands the problem (what is the purpose of the creation of the product).
This is achieved by:
- defining and delimiting the problem,
- identifying the different types of users,
- understanding their needs,
- identifying their expectations.
2. Construction of the product backlog
Once you have a global understanding and visualization of the situation, the next stage is the construction of the product backlog. To do this, you must list the activities that will be necessary to meet the user's expectations.
Basically, what you are looking for is to answer the question about what the user will do with the product, starting from:
- the logical order of actions (from left to right),
- the description of these actions, using simple and clear verbs.
To have a clearer visualization from the beginning of the process about the priority of each activity according to the user, you can assign post-its of different colors.
3. Association of activities and tasks
Once the actions have been categorized (high-level activities, activities of lesser importance, etc.), the set of tasks related to them will be defined, which will allow fulfilling the objective of the project.
For each activity, define with your team what are some of the tasks that the user would have to perform to complete the activity. As a kind of roadmap, where the tasks are listed from top to bottom, constituting the columns of the map.
At this stage, prioritizing the user stories can result in the development of the Minimum Viable Product (MVP), which consists of a preliminary version of the product that will allow you to gradually improve it.
4. Subdivision of tasks
From a first approach to the would-be product, you now have more elements to break down the tasks into sub-tasks and re-organize them. This time, consider the possible variations, exceptions and details that may arise.
A good practice to ensure that nothing is missing is to approach the exercise from different perspectives. This way, it is more difficult to leave gaps or considerations to be addressed.
Just as it was done at first, and without losing sight of the fact that the user story follows a common thread, give priority to sub-tasks, placing them in the user story mapping according to how necessary they are to fulfill the others.
5. Iteration and adjustment of the user story
Now that you have almost fully constituted the map of the story, move from left to right to get a slice of what your product could do. In other words, an iteration or sprint.
The goal will always be to make sure you are achieving the proposed objectives and offering solutions to users that are in line with their expectations.
☝ Last but not least, and as with any other process, check the model for improvement opportunities.
List your SofwareUser Story Map: example
Let's see a practical example of how to use user story mapping. Assuming you have e-commerce:
- In your problem definition, you identify the different users: consumer, site administrator, analysts, salespeople, etc.
- Your list of activities includes, in the case of a consumer: visiting the site, searching for products, buying, etc.
- The tasks associated with these activities include: adding products to the cart, choosing delivery conditions, entering personal information, paying.
- The sub-tasks that arise from the tasks could be everything related to the payment gateway, the option to continue shopping, etc.
- How to improve the customer experience is determined by analyzing what other services and facilities you can offer.
Visual story mapping: the difference with the product backlog
What is known as a product backlog or requirements gathering simply corresponds to a to-do list.
Rather than being a list of activities, the user story map is like a two-dimensional backlog that provides context to the list. This helps the team focus on development and can provide greater value to customers, thus obtaining the desired results. It focuses on the customer journey.