User Story Mapping Workshop: From Chaos to MVP

After countless plan changes and some burned resources, the time has finally come — we can release our mammoth project. At first the excitement is high, but it quickly turns into a feeling of deflation.
With the help of a Story Mapping workshop, we want to prevent exactly that by putting our users at the center.

When I started at vetevo GmbH as a UX consultant in early 2017, the company was in transition, with a brilliant idea up its sleeve. The first steps toward realization were already visible. Unfortunately, like many young startups, they had too many ideas and too few resources, so while they had a lot to show, nothing was truly functional yet. The road to the goal seemed almost endless. The team may have been small, but their ambition and belief enabled them to achieve truly great things.

To get the project back on track, we decided to run a User Story Mapping workshop — I’ll explain exactly what that is using an example project:

No Story Mapping without a User Story, no User Story without a Persona

The foundation

Before we impatiently start writing our User Stories, we need our Personas — they are the basis on which we build the Story Mapping workshop.
You can either build on your company’s existing personas or create new ones. For the latter, you have two options.

• Create a couple of quick “Lean Personas” with a few stakeholders involved
• Run a Lean Persona workshop for your team

The latter has the big advantage that you create the personas together, so everyone can identify with them. I won’t go into a Persona workshop in detail here, because in this article I want to focus mainly on User Story Mapping.

At the end of the day, we want to carve out your project’s MVP/MVE so you all share a sense of the challenges ahead — in my experience, this is the moment when the true scope of the project becomes clear for the first time.
But don’t panic, from here it gets better quickly again. Don’t get discouraged!

The team determines the quality of the workshop. The more diverse the team, the better the result.

The User Story

Before you start, you should already have defined a main User Story. Make sure you bring all relevant stakeholders — designers, developers, project managers, etc. — on board for your workshop.

Your job isn’t to build more software faster. It’s to maximize the outcome and impact you get from what you choose to build.

Possible participants for your workshop

Before you dive into the workshop, clarifying the relevant parties is essential. The best workshop in the world won’t help you if you don’t invite the right people. So think ahead about who should participate and plan in advance.

Scheduling 1–2 weeks ahead is a good start to ensure all relevant parties can attend.
Here are a few ideas for potential participant groups from which at least one person should join.

• 

  Developer

  Always curious and skeptical, no one knows the technical possibilities better. Their insights into feasibility and unconditional cooperation are mission-critical for the project.

• 

  Marketer

  Who could know better what customers like? They spend all day marketing the product and understand what resonates.

• 

  Customer Service

  No one knows your customers’ pains better than the customer service team, so make sure to get them on board. But remember that users often present the symptom, not the root cause.

• 

  Management

  Without C-level support, you lack the necessary backing. A delegate can already work wonders here. At the end of the day, the best ideas and workshops won’t help if the support is missing.

• 

  Designer

  The creative mind behind your product. They largely determine how customers use and perceive it. Try to have one of the company’s designers involved, whether UX, UI, IxD, consumer designer, or service designer. They work on the core and their insights are invaluable.

• 

  Product Owner

  Their highest goal is the product’s success. They plan the backlog with you, clear the path, and keep the project on track. It’s a very good decision to bring them on board.

The workshop is the centerpiece

Do not neglect the warm-up phase and the closing phase. Plan plenty of time. On average, you won’t get through the workshop in under 6 hours.

For the warm-up, I recommend a “Doodle Jam,” for example. Look at the project from a holistic perspective and think about which warm-up would be most efficient for the current project and team situation. Often it’s good to build empathy in a playful way first — after all, we all want the best for the project and our users.

Before we can start the workshop, it’s important to define the User Stories. You can either do this beforehand so that on the workshop day you and your team can focus on the actual mapping, or you can create them together as part of the warm-up. Always keep your target group in mind and don’t forget who will ultimately use the service, tool, idea, or product. A typical User Story might look like this:

After the warm-up

To make sure all participants are on the same page, I’ve found it helpful in recent workshops to go through the personas after the warm-up and read their User Stories out loud.

Post-it time!

We start with a short thinking exercise. Try to list all the tasks the user needs to accomplish. It’s best to go through the individual User Stories for this.
This might look like: “After a successful conversation with his colleague, David wants to schedule a meeting and picks up his smartphone to add the appointment.”
What does he need for that? For a calendar app, it might look like this:

Creating the backbone

After you and your team have written down all the necessary tasks, we create the backbone of the story map. To do this, we group all the existing notes with the team and then try to find a heading for each group.

Keep your User Story in mind and consider what might be most important for the user, for David.

Does the user need a list of appointments before creating a new one? Probably not. ?
In rare cases, two tasks may need to be completed simultaneously. To make the parallel flow clear, you can place the tasks one beneath the other.

Going deeper

After we’ve built the backbone, we go a level deeper by considering exactly what we need for each function. It’s best to walk through the individual tasks using the User Story and identify the required building blocks based on that.

Toward release planning

In this step, we break the tasks into holistic releases. In plain terms, we decide which features deliver the greatest value to the user.

• Which features are essential to your project?
• Which features let you build an initial release to gather user feedback?

To give users a first impression of your vision and collect early feedback, you should always keep in mind that the priority is to get an MVP up and running.

Conclusion

You might be thinking, “Yes, but I can’t boil my product down to an MVP. Why would users use it then?”

Believe me, you will save an incredible amount of time and nerves if you agree on a solid MVP and launch it early.

For more information on the topic, I recommend the book The Lean Startup. The book already provides a solid introduction to the topic.

Remember, this is a digital product and you can always iterate.

At the end of the day, your User Story Map might look something like this. You and your team should now have a better feel for what lies ahead. In my experience, the map helps the whole team focus on what’s essential.

For the grand finale, you or the SCRUM master now have the honorable task of translating the resulting items into the ticketing system of your choice (Jira, Trello, Microsoft Planner, etc.).