Hi guys, in this post I want to share a nice technique that I applied several months ago with one of my teams. I want to explain the value of User Story Mapping. Learn why it is important and how you can run this powerful method on your own.
What is user story mapping?
User story mapping is a useful way to discover the whole picture of your product. Quite often teams tend to get lost in their passion for new individual product features. User story mapping is a powerful tool for software development that can help your team to stay focused on the customers real needs.
What you can expect:
This method will help you to get the same understanding of your product in your entire team and can even help you to distribute this information to your whole organisation. If you are fighting to convince stakeholders in your organization to get on the same page, or if developers are struggling to get the big picture – Story Mapping will help you!
It’s an ideal tool for teams to take decisions in their grooming meetings and prioritizing their backlog. User Story Mapping is a productive way to generate user stories and allows the team to visualize real options for their product.
How story mapping works:
Product Owner, Developers, Stakeholders & Facilitator
preparation: 30 minutes
story mapping: 3-4 hours
The Business Model Canvas
It’s important that the complete product team has a common understanding of the business model in order to understand the purpose of the product. Otherwise you might miss some ideas or some of the team members will think in a complete different direction. It’s necessary that the stakeholders take part in the very first session to present the complete business model to the product team. The best way to summarize all points of the business is a pretty common template called The Business Canvas Model – a strategic management and lean startup template for developing new or documenting existing business models. This visual chart with elements describes a firm’s value proposition, customer segments, infrastructure and finances.
Once the stakeholder explained the business model, everybody should have an idea about the customer segments which are involved in the product. Usually it’s not only the end-customer. There might be also the call-center person answering phone calls from the customers or the secretary who is using a part of a software to administrate data.
Get to know your personas
Probably one of the most important part of user story mapping is defining your personas:
A persona defines an archetypical user with specific attributes, an example of the kind of person who would interact with an organization or product.
Stakeholders and Product Owners should know about the customers’ profile. Talk about every customer segment. For each create a persona, giving them a name with some properties like in the following examples:
Don’t fall into a trap! Create only the most relevant personas regarding the business. After this session you have several filled out sheets with personas, including name, job, salary, needs, likes and dislikes. Before you continue with the next step, ask the complete team if these users meet the reality.
by Jeff Patton
by Gojko Adzic
by Gojko Adzic
Defining the users´ goals
Form groups of 3-5 people. Ask every group to pick one persona and let them brainstorm about the main goals regarding your product:
What are the main goals of the persona Mike Miller?
You will probably generate some goals like:
“Mike wants to get from A to B”
“Mary wants to manage data”
These non-functional requirements should be defined by each group for every persona you defined in the previous step. Once all groups finished, let them put these goals on a wall:
Defining the users´ activities
In this step you walk through the user scenarios. Ask every group to write down the activities that are necessary to achieve the goals you defined for each persona. This is the point where you create the first epics, a higher level of user stories. Some examples for the goal “Mike wants to get from A to B“:
Mike wants to book a ride
Mike wants to register
Mike wants to pay
Deriving User Stories from Activities
Now you can derive user stories from the activities you defined in the previous step. After going through every activity you should have a bunch of vague user stories:
Activity 1 => Story 1, Story 2, Story 3
Activity 2 => Story 4, Story 5, Story 6, Story 7
Activity 3 => Story 8, Story 9
Keep in mind that the result does not have to be perfect at the end of the day. There will be always more activities and stories. The main objective is to get the big picture and a list of stories for the next sprints. Avoid to create a backlog of user stories for the next 6 month. You will run the risk that your super backlog will not work out with the reality.
In the last step prioritize your user stories by the KANO Model. The Kano model is a theory of customer satisfaction which classifies customer preferences into five categories:
- Must-be Quality
- One-dimensional Quality
- Attractive Quality
- Indifferent Quality
- Reverse Quality
Watching at all your stories, you should be able to map all of them to one of these categories. This will give you a direction and you will know what to do next.
A User Story Mapping triggers a lot of conversation in your team. You are able to figure out dependencies on a higher level which helps you to reprioritize your backlog. Read also my article about Impact Mapping, a planning technique that helps you from getting lost while building products by clearly communicating assumptions and business objectives in order to make better roadmap decision.
If you want to dive deeper into the topic or if you want to learn more, read this book from Jeff Patton & Peter Economy: User Story Mapping: Discover the Whole Story, Build the Right Product
Feel free to use part of Story Mapping. I would love to hear how it went.
Leave a star rating for User Story Mapping: