Claim Your
Product Coins
Are you tired of continuous scope changes and never-ending projects without clear ETAs? Or, are you frustrated by stakeholders constantly asking, "WHEN IS IT DONE?" without receiving a clear answer from your team? If so, keep reading!
This blog post shares deep insights on the user story mapping process and how you can use it as insurance to plan and deliver your upcoming features well-scoped on time.
First, let's dive into the basics of user story mapping:
User story mapping is a workshop-centric methodology where you map out user activities. These activities can be performed in specific ways, which are user stories or “options.”
This methodology brings people together! A group of Product Managers, Designers, Engineers, and Domain Experts (stakeholders) is perfect for mapping out and planning a future product, feature, or service.
The goal is to develop a common understanding of how the user interacts with the product before developing or designing it.
On top of that, all created user stories will be added to the backlog which makes planning faster and more efficient.
There have been many occasions where I’ve started preparing or even developing products without knowing enough about the user’s needs and activities...
… that’s why I’ve created this blog post to help you avoid the mistakes that I made.
We’ll focus on:
There’s one more thing I need to let you know...
The only way to learn user story mapping is by doing it. Take one of your current features, write down the user's journey, and start breaking it down into single steps from start to finish. Remember to include all the possible steps, whether all users take them or not!
Once you’ve mapped out your first feature, you’ll start seeing the benefits.
First, we’ll focus on preparing two things:
These two topics are vital if you want a successful outcome. Remember this quote:
“By failing to prepare, you’re preparing to fail.” - Benjamin Franklin
Before you hold a story mapping session, you need to know what topic you’ll be working on. That’s why you’ll need to prepare the product/feature (further called: feature).
Once you pitch the feature to the attendees, they might have some questions. Make sure your feature is as prepared as possible and cover things like:
You can find all the information you’ll need about feature preparation in my article about 👉 User stories and epics 👈
I always prepared either an epic or I use a canvas to visualize the project.
The better you prepare the feature, the better the outcomes of the session.
The workshop preparation starts with inviting the right people. I’m a big fan of smaller groups. I recommend not working with more than 7 people.
Note: Feel free to start with a smaller group and an “easy”/small feature.
The team setup can be different depending on your organizational structure and company size.
Here’s how my typical invitation list looks:
Once I know who’s attending, I create an agenda for the meeting which can look like this:
Hi All,
In today's session, I'd like to pitch & map out “OPU-592 Apple Pay Checkout.” Please check the documentation beforehand:
www.name.atlassian.net/wiki/spaces/EN/pages/project+name-OPU-592
If you have any questions or feedback feel free to reach out to me.
Agenda:
Looking forward to seeing you soon.
Best,
Christian
If you hold the session in person make sure you book a room with:
If you do it remotely, make sure you have set up all the tools. I’ll talk about tooling later as well. What’s important for you though is to take a short look (again) at this article to remember the basis of:
👉 How to get started with user story mapping 👈
Now it’s time to look into the whole methodology and science behind user story mapping.
In this chapter, we’ll have a look at:
Kicking off your session:
If you’re story mapping for the first time, it’s crucial to explain to everyone what it is and how it works. Ideally, you do this before the session.
I’ve created a slide deck that I use when I coach people. Feel free to copy and reuse it. 😉
Link: Intro - User Story Mapping
Let’s jump to the feature pitch!
It’s essential to nominate a note-taker who writes down feedback and questions at the beginning.
All open questions for the whole session should be added to a “Parking lot.” In the end, you can decide who follows up on specific subjects with an ETA.
I like timeboxing the pitch, including Q&A, to max. 15 minutes.
If you need more time, the feature is very likely not ready to be “story mapped.”
The 15 minutes is a suggestion. You decide how much time you want to spend on this.
If there are too many questions or they’re all critical ones that can’t be answered, I recommend stopping the session! Continuing without enough data is a waste of time.
Once you’re all up to speed and aligned on what to build, it’s time to start with personas and activities.
In “How to get started with user story mapping” I outline the basics of story mapping for customer-facing features.
A user story map shouldn’t only reflect the “happy path” but should also examine what’s referred to as “edge cases” too. In my article, I use the example of adding a credit card. You have 3 different possibilities:
Every flow is different and might involve different personas and processes. Therefore, I recommend separating them like you separate your MVP and further releases. In the case of activities, you do this on a vertical level.
When you present them to stakeholders, you can hide/collapse the edge cases and start, for example, with the happy path.
If you don’t manage to cover all edge cases, don’t worry. You have a smart team that’ll review and challenge the story map.
Sometimes a user or persona can be “technical” like a 3rd party. These external or internal systems handle certain business processes.
It can be very helpful to visualize them in order to map out the full process. That helps Engineers and Product Managers to fully understand how the feature will work.
Nevertheless, it shouldn’t be used to define complex backend processes. It’s the job of an Engineering Team to think about a solution. Everything else is a waterfall approach.
The Apple Pay example from my article didn’t include any technical personas and business processes. However, the payment service provider plays a key part in the whole flow/process which I have visualized below.
Note: I’ve no idea how Apple’s backend works. This flow is just an assumption for visualization purposes.
Recently, I coached a team (working in fintech) that was building multiple backend features. They just got started with user story mapping and had an overall low amount of product documentation in place.
The very first thing we did was “story” map the existing functionality in order to develop an understanding of how the business and backend processes work. This helped the Product Team immensely when it comes to understanding how the systems work.
We also reused and built upon these story maps with all new functionalities.
Conclusion: It can be helpful to include technical or 3rd party/system personas to visualize business processes. It shouldn’t be used to design backend processes.
The next chapter will focus on my favorite part of the process: MVP definition! And for sure there’s some further read on that topic as well: 👉 How to define an MVP with user story mapping 👈
By this point, you should have an understanding of most of your personas and have a backbone in place for your activities. Now we need to start building out our map vertically by adding user stories.
Think of more user stories/options rather than less. You can always scope them out!
Once your user stories are specified, you’ll define the minimum viable product (MVP) or minimum marketable feature (MMF). But the work doesn’t end there.
Drawing the line means deciding on what’s in and what’s out.
You might scope out functionality for the first version that’s needed to be competitive, compliant, etc.
Therefore, we’ll have a closer look at the whole MVP and release planning process to ensure you hit your customer and market needs.
I always draw the line twice. Check out this short video where I demonstrate how I draw lines.
Firstly, with the group that created the story map and secondly with my Engineering Team.
Let’s take a look at the first MVP definition.
Many people believe that an MVP only contains the very bare minimum functionalities. It’s often referred to as a “Skateboard.”
Nevertheless, you can’t always launch the bare minimum of what makes a feature “work” or the skateboard “roll.” There needs to be more substance.
That being said, if you want to launch something fast and learn along the way, building a skateboard is fine.
If you're working with a well-established product, I recommend making sure the MVP covers key functionalities that customers expect and ones that make you a viable competitor in the market. Especially in B2B!
Here are the Product Management skills you’ll need! You and your team must be fully aware of the problem you want to solve and the business goal(s) you wish to achieve. Make sure everyone is on the same page.
I always use the second round to review the MVP with the Engineering Team. They know what’s best, what can be built fast, and what’s going to take more time than expected. The insights I gather from my teams help me to better prioritize and achieve a faster go-to-market.
On top of that, they’ll help you to complete the list of stories if you missed any. 😉
All stories that didn’t make it into the MVP will fall into further releases. Therefore, you’ll need to have decided what’ll be shipped in the second, third, fourth iteration, etc.
Most teams correlate upcoming releases with sprints, iterations, or release trains. And that’s fine. Nevertheless, I’d like to share some advanced thoughts on that with you.
Do all stories that are defined need to be shipped at once? Or, can you launch increments of the “release” that deliver end-to-end value once they’re ready?
That depends on the product you’re building and on your technical infrastructure (continuous deployment, etc.).
I work with a gaming company that always defines user stories in a way that they can be shipped independently. Once all stories are in production, they tick off the “release.” ✅
I found it very inspiring, helpful, and worth sharing with you.
Note: This brings us back to using the INVEST framework for user stories and another good night read: 👉 How to break down features before you start developing 👈
Previously, we touched a bit on the topic of discussing the story map with your team. Now, we’ll dive deeper into that as well as how to get stakeholder buy-in.
FYI: This is a great podcast episode about user story mapping with some useful tips & hacks
Once you’ve created and aligned the story map with the workshop team, you’ll need to get input from your Engineering Team. I believe it’s important to have a good structure in place to share the story map with your team so you can get the best possible results out of it.
Depending on the feature size, I’d recommend at least 1 hour to cover 3 key points:
Since you’re used to it now, it shouldn’t be a biggie. 🙂
I always hide all stories/releases and start with the personas and narrative flow (activities) first. I like going through it before I answer questions. If the map is very long, I have a break in between and ask if anybody has any questions or if anything needs further clarification.
Next, I share all the user stories on the screen. The fun part is that I don’t explain them. I let the team split up into groups and select parts of the story map they want to analyze.
The result is that they come up with:
Depending on the story map size, I do either one or more breakout sessions for 10-15 minutes.
I highly recommend trying it out. The results of your team will be outstanding.
Alternatively, you can go through the user stories with your team one by one.
In large companies, such as B2B enterprise businesses or agencies, it’s essential to get the buy-in and feedback from stakeholders. As much as we don’t like it as Product Managers, sometimes other people do have the last say.
In smaller companies that are used to user story mapping, sending an email with the link to the epic (feature) and the story map can be enough.
In larger or more complex environments it’s necessary to pitch it in a meeting. I recommend pitching it with at least two people together. One presenter (usually the PM) and one note-taker. Doing both can be very challenging and overwhelming.
You can follow the same 3 points without the story breakdown. Stakeholders should mainly give feedback on priorities or provide feedback you can follow up on offline.
Don’t fall into the trap of discussing user stories in-depth or how the future UI should look.
That can happen quite fast if you pitch it to a passionate founder for example.
If you managed to pass the pitch and got the buy-in, you truly mastered the whole user story mapping process! Well done mate! If you are still up for one more little hack keep reading! Here comes the tooling part I promised…
I like onsite meetings the most. Nevertheless, more people than ever are working remotely these days. That’s why it’s crucial to have good tooling in place for
I’d like to share with you how I deal with tooling and how I make sure to keep the key information for Engineering Teams all in one place.
In a remote story mapping session, it’s good to have one person who shares the screen and creates virtual sticky notes.
For a long time, I used Google Spreadsheets which isn’t a bad solution. Spreadsheets give you the freedom to design things the way you want and the comment function is very helpful too. Another benefit is that everyone can collaborate on it in real-time.
During the activity creation, it’s important to keep all team members involved. There can be instances where some people with a clear picture or strong opinions dictate the whole flow (in remote sessions even more than onsite ones).
I recommend that as a Product Manager, you regularly ask team members directly about their opinions to make it as interactive as possible. Helpful questions to ask people or the group are:
These are some simple but engaging high-level questions I always like using. I’m sure you’ll know much more than I do.
These tips can help to get the most out of a remote or onsite session.
Unfortunately, story maps don't look nice or clear in spreadsheets. Besides that, it’s not connected to Jira or any other project management tool.
I tried multiple story mapping tools over the last 4 years, including the latest story mapping functionality from Miro.
Most of them miss needed functionalities or haven’t got good Jira integration.
At the start of 2019, I found Avion.io, which I liked the most out of everything I’ve used so far. The UI is clean and simple, and the best thing is it pushes and pulls tickets from Jira.
Once you’ve created activities and user stories, they’ll be pushed into your backlog. If you change them the changes will be pushed back.
That means your story map will always stay up to date and become a reliable and updated source of documentation. On top of that, you don’t need to create tickets manually in Jira anymore. Win-win.
This can be very helpful if you want to story map your whole platform and have all story maps in one place plus a smooth connection to your product backlog.
Here’s a short YouTube video of Avion.io👈 Feel free to give it a try!
If you have good experiences with other tools please let me know. I’m always happy to experiment with new solutions.
I know this was a long read… Let me know how you're progressing and let's chat on Linkedin.
