How to discover the big picture of your product with story mapping

user story mapping

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:

Persons needed:
Product Owner, Developers, Stakeholders & Facilitator

Time needed:
preparation: 30 minutes
story mapping: 3-4 hours

Business Model Canvas
Get to know your personas
Define the users´ goals
Define the users´ activities
Deriving user stories from activities

The Business Model Canvas

Business Canvas Model

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.

customer-segmentOnce 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.

Related books you may like:
1 User Story Mapping: Discover the Whole Story, Build the Right Product
by Jeff Patton

2 Fifty Quick Ideas to Improve Your User Stories
by Gojko Adzic

3 Impact Mapping: Making a Big Impact with Software Products and Projects
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:
1 Star2 Stars3 Stars4 Stars5 Stars (12 votes, average: 5.00 out of 5)


Leave a Reply

Required fields are marked *.