How to Define an MVP With User Story Mapping
In the first part, we looked at the basics of a user story map and the story mapping creation process. I hope you didn’t develop a sticky note phobia after your first story-mapping session.
So, what happens after you’ve created the first version of a story map? Who do you pitch/present it to? How can you find an agreement on the MVP/MMF and most importantly: How do you present it?
Next, I’d like to look into what stage of the creation process you need to pull in the right people to ensure you all align and agree on a result most efficiently.
Let’s look at the story mapping process again:
As I mentioned in “How to Get Started with User Story Mapping” a group of 3-7 people works best. Ideally, a Senior Engineer who is part of your team or works in the same domain should be part of the session. This person can help from the beginning to consider technical aspects during the story mapping process.
You (the group) have worked out a story map and defined an MVP/MMF. Keep one important thing in mind; The MVP is not set in stone yet. As a next step, it needs alignment with the Engineering team(s) as well as the stakeholders. How to start now?
Pitching the User Story Map to Your Development Team
After you’ve created the first version of the story map, you’ll present it to your team. I recommend blocking 2 hours in your calendar.
Your agenda could look like this:
Pitch the new feature
Story map presentation (persona & activity)
Review of user stories
Questions, feedback, and next steps
It’s up to you if you want to add documentation such as an epic and the story map to the invitation or not. Whether you’re onsite or remote. I like showing everything for the first time once it’s live. However, if you want your team to prepare upfront you can also share all relevant links in the invitation.
1. Pitch the “Why” and the Goal of Your User Story Map
With the first version of your user story map defined, you’re moving one step closer to the start of development. Therefore, it’s very important to give your team a full understanding by going through the background. I spend the first 10-15 minutes explaining the feature and all related data in-depth and answering questions from my team. In our day-to-day business, it happens quite often that the Product Managers jump directly into the story map. Don’t forget or underestimate the power of alignment and clarity. Take time to explain and educate your team members on the topic.
Note: Taking notes and writing down open questions is worth a lot 😉
2. Go Through Your Map; Start With Personas & Activities First
If you present your user story map on e.g. Google spreadsheets, I recommend hiding the user stories and only presenting personas and activities. I present them from the beginning (left to right). Here’s a suggestion for how to pitch the above story map:
Persona iUser unlocks the iPhone.
Then he/she opens the wallet app.
Sometimes you have multiple personas inside a story map. Take a short break whenever you switch to a different persona and ask people if everything is clear or if they have questions.
Important: Make sure you are not driving off the track when people ask questions. Focus only on high-level or clarifying questions. Details will be discussed later.
3. Looking at User Stories and Options
Now the fun part starts. I’ll now share different ways you can go through the user stories. This depends a lot on your team size, the location, and the complexity of the user story map.
One way of presenting user stories is to take the whole team through each story. That means explaining it like:
Persona iUser unlocks the phone by using Face ID. Then you go on to the Passcode. And so on…
If your team is small and has no dependencies on other teams, you can discuss every single story with them.
Another way to go about this is by selecting a couple of activities with user stories and timing them. That means your team reads the user stories by themselves, discusses them, and gets back to you after the set timeframe with questions. If you have a bigger team, you can also split them up into groups and each group can discuss things separately.
If a story map is longer with multiple user stories, there is a chance you won’t be able to finish it in one session. Be prepared for a follow-up meeting.
How about dependencies to other teams? 🤔
Sometimes a story map touches multiple domains and teams. When this occurs, you’ll likely have created the story map with other Product Managers. That means that every PM will need to go back to their teams and present the user story map. It’s important to let your team know that other teams are involved. They’ll automatically think of dependencies and add feedback. Alternatively, you can bring all teams into one room and pitch it to all of them and discuss them.
I’m personally not a big fan of this because those meetings can stray off the track very quickly because of too many opinions. You need a very good facilitator who can cut conversations if they’re not relevant. Another idea is to invite representatives from each team to the meeting to keep it small.
FYI: If you want to dig deeper into the whole topic of defining an MVP and planning releases in an advanced way I recommend checking out this podcast episode.
4. Discussing the MVP Line on Your Story Map
Obviously, your team has a big say when it comes to the definition of the MVP/MMF line. Why is that?
The discussion about the user stories is the part of the session I like most. The Engineers will tell and consult you on how to best approach the development process. For example, let’s take a look at the first activity “Unlocks the phone”.
A conversation between you and your team could look like this:
PM: What do you think about scoping out the push notification story?
Engineer: We do have all functionality in place and just need translated content.
PM: Are there no configurations that need to be set?
Engineer: Yes, this won’t take longer than 4 hours including QA (testing)
PM: That sounds great! I talked to the Marketing team already. We can get the translations by the end of next week if we like.
Team: OK let’s move the card up then and make it part of the MVP.
Alternatively, activity 6, could be discussed like this:
PM: What do you think about implementing a new API?
Engineer: We do have that functionality already in place for another feature.
PM: How much work is needed to make it run for the Apple Pay feature?
Engineer: It requires a bit of work but we don’t need to integrate the complete API again. I believe max. 2 days.
PM: Great that means we save a lot of time...
I could take you through many more examples. But bear in mind, that most importantly:
The communication and alignment part is key. It’s crucial that you’re all on the same page. The time you spend now in conversations and discussions will save you time later on during the development stage.
Pitching the User Story Map to Your Stakeholders
After you’ve reviewed the user story map with your team, you should have a better overview of how to approach the whole product/feature planning. However, there are other interest groups aside from your team who would like to know what you plan to build. Sometimes, these people do have a say as well in the whole MVP definition.
An example could be your VP of Product or a Sales team that negotiated the contracts with a customer.
A Different Setup to Pitch Your Story Map
When I pitch the story map to a selected list of stakeholders I make sure that one or two people from the story mapping group join the session. It’s important to have different roles during this meeting:
One person focuses on pitching the story map as well as the feature (ideally the Product Manager).
Another person takes notes and open questions.
If there is a third person, he or she can be a moderator and can ensure you don’t go off track.
I start sharing all relevant information about the feature/product first. Then continue with questions and move on to the persona and activity stream...
During the user story discussion, you might get feedback from your VP of Product who thinks a particular user story that isn’t part of the MVP should be moved above the line. Or a Project Manager will tell you that a particular user story has been promised to a customer.
Note: The pitch to the stakeholder should normally be shorter than the one with your team. I usually block 1 hour, max 1.5 hours with stakeholders.
Defining Your Minimum Viable Product
If you’ve gotten feedback from all the different parties it’s up to you to make a decision on how the product will look. That’s a decision I personally can’t make for you. No matter what you decide, make sure you communicate it back to all involved people. Share an update with your team members and stakeholders to make sure they’re in the loop. Take 10-15 minutes in the next team meeting to present the final version and explain your decisions if the story map has changed.
As a next step, you and your team need to start preparing the backlog. If you want to know about project preparation you can continue reading here:
