Have you ever experienced a situation where you have a huge thing in front of you and you don’t know which side to start from? Are you struggling with how to grasp the breakdown of new functionality so that you deliver the most value to the customer as soon as possible, and then work on the other parts? The User Story Mapping method, which is used to break down large units into smaller ones, can be very useful for you. We have therefore prepared a practical step-by-step guide that will take you through the technique.
What’s this about?
Visualizing user flow over time – visualizing the actions a user takes in the system to achieve a (predefined) goal.
A useful tool for creating a skeleton Backlog for a Team or Squad.
The resulting map helps the Team and Product Owner to prioritize and determine what is really important to the customer.
The first output of User Story Mapping is a set of User Stories that together form an MVP (Minimum Viable Product).
How to use this method?
- Select representatives of different roles – Developer, Designer, Tester, Product Owner (ideally max. 10 people).
- Ask the Product Owner to write a short description of what needs to be mapped, ideally in the format:
- WHAT – the product, new functionality he wants to add, or a problem he needs to solve;
- WHOM FOR – describes the customers of the product or the users who will use the functionality. For each such user, explicitly describe what it brings to them;
- WHY – describes the reason why the company decided to create the functionality or product.
- Set aside 2-3 hours of time and space with a large board or wall.
- Start by introducing the Product Owner’s input and continue with a common definition:
- Start Point – the point at which the user enters the system, and begins their interaction (e.g., User logs into the internet banking web interface);
- Target state – the target state where the business/customer need is fulfilled (e.g., User has made a financial transaction).
- Together as a group, create the Backbone of the Story Map by naming the larger activities that the user must do in the system to achieve the goal defined in the previous step. Visualize the activities on the wall/table from left to right as they follow each other in time.
- Break each activity into smaller parts – called User Tasks. Think about:
- Alternative ways in which the activity can be implemented in the system;
- What edge cases might occur (something doesn’t work, server crashes, etc.)?
- How would different users of the system approach the activity?
- The details of the activity and the various enhancements;
- When creating, try to vertically prioritize according to the value and importance of the customer task.
- Mark on the map the first smallest cut from left to right by which the customer is able to achieve the defined goal – the MVP release is created (shown by the red line in the figure).
- Continue by marking additional cuts, each of which adds more new comprehensive functionality for the customer. The rule is – 1 cut = 1 release. When designating additional cuts, you may consider:
- Different personas – you can target specific increments/releases to specific types of users (e.g., target enterprise customers after MVP delivery and prioritize individual user tasks based on that);
- Add other key options and alternatives to the product based on importance or most common use case.
- After building the User Story Map and defining the slices, you can “flip” the result into, for example, JIRA and have an initial Backlog.
- One slice ideally represents one Epic.
The priority in the Backlog is given by cutting from top to bottom and then by columns from left to right (see the numbers in the bottom right corner of the cards in the picture).
When is the technique not suitable?
A new product or functionality requires no or minimal user interaction in the system (e.g., background technical changes, refactoring, etc.).
New functionality is only a small change in a huge working system (mapping the existing system would take a lot of time).
You only want to map Stories that you already have figured out in advance (people won’t take the result as their own, because everything is already given in advance).
If you are not able to bring enough different roles into one place – you may miss out on important ideas, perspectives, questions, insights (minimum is Product Owner, Developer, Tester and Designer).
If you would like to try the technique in practice, feel free to contact us, we would be happy to guide you through the workshop from start to finish using a specific example from your practice.
