User Story Mapping: Discover the Whole Story, Build the Right Product

by Jeff Patton

Slice out a development strategy. If you’ve sliced away everything you don’t need to deliver, you’ll be left with what you do need. Now slice your minimum viable solution into the parts you’d like to build earlier and later. Focus on building things early that ...

On the day of the workshop, we typically start with a product vision exercise such as the well-known Elevator Pitch or the Cover Story[8] format where the team describes what they would like to read about their product in a trade journal article a year from now. This shows whether the team has a common understanding about

The next step is to look at the typical users of the product. If the workshop goal is to specify a detailed backlog, the user roles or personas should result from the user research phase. If the project is in an early phase, the team writes down their assumptions. These can then be tested in user research phases. This has proven to be a good way to prepare the user research. This is also an aspect where design thinking practices and user story mapping work very well together.

We next use a three-tier approach to defining user stories: (1) starting with high-level usage steps, these are broken down into (2) finer activities per user role, which in turn are broken down into (3) concrete user stories in the format “as <role>, I want <functionality>, so that <value

Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.

So the idea is telling, and you know you’re doing it right if you’re generating energy, interest, and vision in the listener’s mind. That’s big. And it sounds a lot more fun than reading a typical requirements document.[

If you’re not getting together to have rich discussions about your stories, then you’re not really using stories.

As a [type of user] I want to [do something] So that I can [get some benefit]

Use the simple story template to start conversations.

“As a band manager, I want to upload an image so that I can customize my promo flyer.”

Really talk about who Please don’t just talk about “the user.”

Really talk about what

Really talk about why

Talk about what’s going on outside the software

Talk about what goes wrong

Talk about questions and assumptions

Talk about better solutions

Talk about how

Talk about how long

There are many different kinds of conversations with different people for every story.

have some bad news for you here. You’re likely to find things you believe should change about what you’ve done. It’ll help everyone’s sanity to separate out two concerns. First: did we build what we agreed to build? And then: if it’s what we agreed to build, now that we see it, should we make some changes?

Who the customers and users are you believe will use your solution How they meet their needs today without your solution How the world would change for them with your solution How your solution might look and behave How long your solution might take to build

product manager to identify a product that’s valuable, usable, and feasible. When

Journey Mapping and Concept Generation Ben Crothers, Atlassian Given that we offer over 10 different products, we have to make sure that we design, build, and improve upon those products in ways that match how our customers use them together, not one by one. As part of a project to discover how the products could work together in a better way, we formed a multidisciplinary team to map the entire end-to-end customer experience in finding, evaluating, purchasing, and using them, as well as getting help and adding more products and services. This was huge. To help break it down, we mapped the experience at a high level first, and then broke into subgroups to expand on each section of that skeleton journey. We did this by initially filling a wall with the moments, actions, and questions that customers go through, color-coding as we went, and then going back over it, adding pain points, opportunities, and assumptions. We gained a lot of insight by being able to trace an end-to-end story rather than just a feature-based experience. We quickly realized, for example, that some parts of the experience—such as setting up products or getting help—weren’t isolated to one part of a linear journey, and needed to be catered for much more and in greater detail. Various other stakeholders and teams were brought in to flesh out more detailed journeys that were all pegged to various points along the high-level skeleton journey, so that we captured and validated as much existing knowledge as ...

What problems are we really solving? What solutions could be valuable to our organization and to customers buying or adopting the product? What does a usable solution look like? What’s feasible to build given the time and tools that we have?

Sketch simple personas I like creating simple persona sketches with a small discovery team to build shared understanding of my users. A persona is an example of your target user assembled from the facts and sometimes the assumptions you have about your users. Building personas helps us look at the software through the eyes of our users. Personas are handy tools.