If you’re seeking to effectively frame a subject or want to involve your Business Owners in a User Story Mapping workshop to resolve an issue or break down an Epic, members of the AXA France Product Family Community of Practice, have designed this Draft.io template for you.
Based on a real-life example, this template will guide you, step by step, to make your User Story Mapping workshop a success!
But first, a bit of history
Story Mapping is a tool created by Jeff Patton (author of the book “User Story Mapping”), whose leading idea is to tell stories (hence the notion of “Story”), in a collaborative way, with words and images, with the aim of building a mutual understanding of a given situation. Stories are a way to start a conversation about a business, a customer, or a user’s issue. This workshop is mainly used to mature and frame “big” subjects at the Epic level.
Story Mapping promotes:
- The discussion and collective creation of a product;
- The shared vision of issues and solutions through the definition of shared objectives;
- Prioritization with the notion of MVP and the implementation of an incremental development process;
- The identification and qualification of risks and uncertainties by the entire team upstream of the project.
Who participates in this workshop?
Usually attend this workshop:
- A facilitator: Product Manager, Product Owner, or Business Analyst;
- The Business Owner(s);
- Member(s) of the Development team (developer and/or tester).
In order for the workshop to be effective, it is essential to bring together only:
- People who know how to ask the right questions;
- People who know how to answer questions.
“If the person building the software could simply speak with someone who understood the users who will be using the software and why they’ll be using it, there’s often a more cost-effective way to delight those users. Without talking, we just never know about it.” — Jeff Patton.
When is the right moment to organize a User Story Mapping?
As soon as your Business owner has prioritized the subject, you can organize a workshop, but not in any way. You can use 2 different tools depending on the subject’s complexity:
- To get a better understanding of a complex subject: User Story Mapping is effective for roughing a subject and refining it into Minimum Marketable Feature (or MMF);
- To deepen a specific subject (the evolution of a customer journey, for example), favor Event Storming/Modeling (this will be the subject of a future article).
How to run a User Story Mapping in 9 Steps
Let’s define a color code for the cards we need
Unlike Event Storming/Modeling, in User Story Mapping, there isn’t really a standard that sets the items and colors to use. That’s why we suggest you this one:
In Jeff Patton’s User Story Mapping, 4 cards are essential:
- The theme which brings together a set of activities;
- The activity that can be assimilated as a Feature;
- The feature that we are going to develop (which, depending on its size, can be a user story, a Minimum Marketable Feature – MMF -, or even a set of MMFs);
- The question that keeps track of the questions asked during the workshop and that we need to answer afterward.
We have added other cards:
- The objective, which is an essential part of Story Mapping, and which will determine the order in which the features will be implemented (this will be the subject of a future article on OKRs);
- The implemented feature: this is a feature that has already been implemented and runs in production. This concept is interesting when you want to differentiate the existing perimeter from the perimeter that is still being designed;
- The technical dependency that the teams can identify from the User Story Mapping (for risk management).
Step 0: Preparation of the Elevator Pitch – The vision of the product
This is the preparatory phase of the workshop. With your Business owner, prepare the pitch that you are going to present to the participants. As its name suggests, this intervention must be short and get straight to the problem to be solved.
Step 1: Elevator Pitch & brainstorming on activities
It’s D-Day. In front of the participants, the Business owner presents their Elevator Pitch. Beforehand, you will ask each participant to write down, on their own, all the activities they heard during the presentation.
Step 2: Define the chronology of activities
The activities written by each of the participants will be shared and placed collaboratively on a time scale, the activities being positioned in the chronological order of the process described.
Step 3: Define the themes that gather activities
Following the various discussions and— you will discover it — in a natural way, the participants will group together the activities that share a common characteristic within a “theme” card. This card is not mandatory, but it can help participants structure the backbone of the User Story Mapping.
Note: It may even happen that there is no theme or that an activity is also a theme.
Step 4: Assign the Persona(s)
Now we identify the personae who will be involved in each activity on the time scale.
Step 5: Define user stories by activity
At this stage, the participants will have to collaboratively describe all the user stories that will be developed for each activity.
Note: it is important to tell the participants not to limit themselves in their reflections because questions and interactions between the participants can make them come up with innovative ideas.
Step 6: Define release objectives and success indicators (or Objectives and Key Results)
In collaboration with the Business Owner, you define the order in which the user stories must be implemented by mentioning:
- The Objective whose aim is to answer the question, “Where are we going?“
It fixes the target of an organization, a team, or a person. It must be ambitious and inspiring. It allows us to reflect together on the questions: “Why are we launching this Epic?”, “Will it have a positive impact on our product?”.
- The Key result answers the question, “How will we succeed?”
A Key result characterizes the conditions for the success of the objective. It is associated with a measurable indicator (KPI). Key results can be measured using a scale of 0 to 100%. For example, 40% of prospects have been relaunched, or 70% of the project has been completed. We can use a numerical indicator such as the turnover generated, the conversion rate, or the NPS, which measures customer satisfaction. If the key result is not measurable, write 0 for not achieved and 1 for achieved.
Step 7: Assign User Stories to Goals
To meet the objectives and, therefore, the prioritization constraints, the stakeholders will move the different user stories by objective. This will be the first form of commitment to what needs to be developed.
Step 7bis: Detail primary features with Event Modeling
During this stage, the features of the primary objective will be matured thanks to Event Storming/Modeling. But this workshop is not part of User Story Mapping.
Step 8: Represent the progress of developments
User Story Mapping lives alongside the product life cycle. It is an excellent visual communication tool to present work advancement.
Step 9: Regularly refer to the User Story Mapping and update it according to new priorities
Since User Story Mapping can become living documentation, it makes it possible to visualize the deprioritization or reprioritization of features.
Do you use a 3-level Backlog?
Here is a suggested correspondence between User Story Mapping and the Epic, MMF, and User Stories backlogs (User stories, Technical Stories, and bugs).
Finally, some tips
Find below some tips to master the User Story Mapping workshop:
- To make the meeting effective, involve your business owners. It will prevent you from wasting time imagining what they might think of having to ask them questions after the meeting;
- Start with a simple perimeter to get used to this workshop;
Note: If you want to update an existing course, you can start just before where you are going to add something new and stop just after it ends.
- Do not get lost in the details; you will have plenty of time to do so when you mature the priority features (via Event Modeling, for example);
- Do not refer to your tools. On the contrary, bet on the features to be provided. Otherwise, your mind will lose creativity because you will focus on what the current tool is capable of doing;
- Regularly present your User Story Mapping to your team and your business so as not to forget the objectives of the current version and keep the overall vision, or refer to it when you go into production;
- Bring your User Story Mapping to life, even after the workshop, to highlight the advancement and changes compared to the initial plan along the way.
“And changing software after it’s built is too often seen as a failure. It’s where terms like bad requirements or scope creep get used to reprimand the people who made decisions about what to build. But we all know that change is a necessary result of learning.” — Jeff Patton.
- Share and debrief with other teams on User Story Mapping to build skills.
One last tip
Use OKRs that will help and guide your team through the development process. It will force you to always answer the question, “Finally, why am I developing this feature?” which can regularly arise after months of development.
Acknowledgment
Thanks to Evelyn Ly, Tiago Marques, and Hélène Perez for helping me create this template.
Resources
“User Story Mapping: Discover the Whole Story, Build the Right Product” — Jeff Patton.
“Measure what matters” — John Doerr.
