Are you User Story Mapping yet?
It’s no secret that communication is one of the most important functions that teams need to do well in order to function. But how can teams with different areas of expertise be sure that they are talking about the same problem, the same solution and the same method to get there? Enter User Story Mapping.
It is a process that helps create shared communication among team members in order to “talk about the user’s journey through your product by building a simple model that tells your user’s story as you do” (Jeff Patton).
Shared Understanding
The primary goal of a user story mapping workshop is to create a shared understanding with your team. After a successful session you all will know what you need to build, to solve what problem for users, and be sure that you are talking about the same thing.
Shared understanding doesn’t come from writing perfect documents. A product document, even the most carefully written one, will help your team visualise problems, the users that have them and, in the best case, the solutions your product will introduce to these problems. But in order to make sure that all the team members understand the same problem, users and solution, you need to bring these people into a room (yes, virtual rooms count) and discuss.
Product/User Flows
After running a good user story mapping workshop, your output will be Product/User Flows. Having explored the business problems behind the current user flows, you are more ready to build new ones in order to solve your user’s problems.
You will not be able to explore every detail of your user flows, and that’s ok. You need to tackle the problems by priority, value, and impact.
How to run a User Story Mapping
Now that you know what User Story Mapping is and why you need to have it for your team. But how do you run a workshop effectively? The main artifact of your User Story Mapping workshop is the board where all the information should be depicted.
Step 1 of 6 – Preparation
As a PM, you need to prepare your User Story Mapping workshop. You need to build a lot of information from the teams and properly gather all the requirements ahead of time. Things you should consider gathering or writing down:
- Business Context
- Personas
- Jobs to be done (for your personas)
- Current user problems
Pro tip: You can find a lot of templates online to help you structure the above information!
Step 2 of 6 – Backbone
In the second step, you need to add all the main activities (backbone) on top of the map, in the order that users should perform them while using the product. The backbone should consist of main user activities that are clearly separated and are not part of the same solid user flow.
Each main activity should have its own internal story (as we will see in the next step) with an intro, a set of actions, and a specific result.
This can include activities like “Organize email”, “Manage email”, etc.
Story mapping flow might not be the same as the final user’s journey in the app. It can also include forks and loops.
Step 3 of 6 – User Steps
After we have established the main activities of our user, it’s time we added the smaller activities, or steps, that take place in each of the main activities. These steps should describe the user’s intro to the activity, the different screens they have to go through. Even though having screens this early is not optimal, it will not harm you to have a visual guide. But do not design wireframes here, it’s too early and not necessary.
This can include steps like “Compose email”, “Read email”, “Delete email”, etc.
Step 4 of 6 – Activities (aka, Options)
Once you have added the steps, you can now start adding all the details that each activity contains, in regards to functionality. This is the step where you need to add all the user actions and interactions with the smaller activities/steps within each “screen”.
Each step must include a functionality of the product or a user action and not something that the development team should do, like manual work or research.
This can include actions like “Create and send basic email”, “Send RTF email”, etc.
Pro tip: Avoid the How
User Story Mapping is about mapping your user’s journey. Shocking, I know 
. You are working on a high level now, in order to help you drill down later on and, of course, create a shared understanding of what your product is trying to achieve.
You should avoid diving into the technical implementation just yet. It’s out of the scope and it will only add obstacles in the process. You can solve a problem in many different ways, but this isn’t the time to think about the technical & design solutions, it’s all about figuring out and agreeing upon the problems themselves.
Step 5 of 6 – Annotate
Annotation is perhaps one of the most important steps in the entire process. Once you have mapped all the particular activities (or options) on the map, it’s vital to annotate on the post-its extra information like concerns or unknowns that will help you focus later on and prioritize. Annotations can include:
- Hard to develop solutions
- Uncertainties on the problem
- UX research needed
- Business obscurity
Pro Tip: You can define the possible annotations from the preparation step.
Step 6 of 6 – Prioritization
The final step of the process is to prioritize the activities and decide what we are going to do first. Prioritization should be based on the value and effort for each option.
Remember the MVP process from Henrik Kniberg? He suggests that we should work towards delivering value to the user using small iterations and re-designing the product instead of trying to deliver the end result all at once. This is where agile takes place.
So, a gentle reminder that priority goes to prioritizing iterations that make sense in both a technical and a business perspective, but most of all from a user’s perspective.
When to run a User Story Mapping
This workshop can be adjusted to any product at any stage of their life:
- MVP: You can run a user story mapping workshop to identify what you need to build first to maximize the value you are delivering to users
- Live product: You should run a User Story Mapping workshop to a) create the map that you hadn’t created in the beginning and b) to see where your new feature will fit in the existing user journey.
Who should participate
User Story Mapping is an extension of the 3 Amigos workshop that each development team can run prior to building each feature. The important improvement is that it adds the business perspective into the mix.
What you should bring to the table
PM: Backbone and main activity builder. The PM is the decision-maker of the workshop
Business/Sales: Brings the business knowledge and the customer experience/feedback/opinion
Engineering: Makes sure that everything discussed is doable, at least with the existing knowledge (but remember to avoid the nitty-gritty of the how)
UX/Design: Becomes the glue between Business and Product, makes sure the steps and user activities are in the right place and make sense
QA: Puts the final touches on the entire process, will make sure that user flows are structured, circles are formed (where necessary)
How we run a User Story Mapping workshop at ORFIUM
For us, the User Story Mapping workshop takes 2 sessions. This gives us more time to identify the user flows for a single product where the users are hard to get and the logic is complex. This is how we can best make sure that the entire team has a common understanding of the problem we are trying to solve and the way we are going to do that.
Step 1 – Find a room (5 minutes)
The first step is to find a room with a whiteboard (or a clean wall would do), isolated from the rest of the rooms. This room will be dedicated to the team but will also allow breaks.
Step 2 – Order post-its (5 minutes)
Post-its are the main material for running the workshop as our main goal is to create the board we’ve been discussing.
Make sure you have enough post-its for everyone to write and add to the board, even if you might end up throwing away some of them.
We use 3 sizes of post-its:
- Large for the main activities
- Medium square for the smaller activities and for the backbone, in a different color
- Small for the annotations
Step 3 – Add Additional Material (Recommended for a physical workshop – 1 day)
We add additional material around the room to guide the participants through the entire workshop but also keep all the references we need.
To make it easier to link the slides on the walls with existing information on an online document, we added QR codes on each slide with a link to the original page with the full description.
The additional material included:
- Jobs to be done
- Glossary / reference / terminology
- Collaboration pattern
Anyone could also annotate or add post-its to the slides and ask questions, and the Business or the Product was there to answer them.
Step 4 – Prepare the Board (30 minutes)
Since it’s the Product Manager’s duty to set up this meeting, she should have at least a draft version of how the board would look like, at least in regards to the backbone. So, we add the initial post-its for the backbone, and perhaps for the main activities, to give the team some structure.
The board could look like the one on the left, by the end of the workshop, where all the main activities have steps and options, along with all the annotations.
Step 5 – Fishbowl Collaboration Pattern
To allow the team to collaborate better and avoid overcrowded boards and too many voices, we introduced the fishbowl collaboration style.
This collaboration style allowed us to have a focus area where every member of the workshop that was in that area was allowed to talk about the board and the post-its. Everyone outside the area was free to explore the room, be on their phone or even read more online.
This way we managed to have our focus on the board and allow each person to clearly write the post-its and explain what they were writing.
Step 6 – Workshop Time
Time: It depends on the size of the product, the preparation, and the team’s experience.
Once we explained all the “rules”, the additional material, and the collaboration style, the team was ready to jump in and start adding post-its.
Clearly, for the first 20-30 minutes we added no post-its. We were asking a huge amount of questions about business specifics and backbone items, but this was absolutely necessary for the entire team to start building a shared understanding.
Prioritization & Release Versions
Keep in mind to have some time in the end to prioritize your post-its in release versions. It’s very important for the team, once they understand the big picture to put the blocks in prioritized order and know what’s next.
References
Ioannis Papikas
Senior Product Manager @ ORFIUM
https://www.linkedin.com/in/ioannis-papikas/