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

by Jeff Patton

Story maps are for breaking down big stories as you tell them.

common way to use stories is to build a list of them, prioritize them, and begin talking about them and then turning them into software one at a time.

Talk and doc: write cards or sticky notes to externalize your thinking as you tell stories.

Think — Write — Explain — Place When working with a team to build a story map, or having discussions about anything, create a simple visualization to support your discussion. One of the things that goes wrong is lots of ideas vaporize—that is, we say them, and people nod as if they’ve heard. The ideas are not written down or referred to. Then, later in the conversation, the ideas come up again and unfortunately need to be re-explained because people didn’t really hear or forgot them. Get in the habit of writing down a little about your idea before explaining it. If you’re using cards or sticky notes, write down a few words about your idea immediately after thinking it. Explain your idea to others as you point to the sticky note or card. Use big gestures. Draw more pictures. Tell stories. Place the card or sticky into a shared workspace where everyone can see, point to, add to, and move it around. Hopefully, there will be lots of other ideas from you and others in this growing pile. I find that when I’m doing my best to listen to others, what they’re saying causes me to think of other ideas. I used to try to hold those ideas in my head and wait for a moment to inject them into the conversation, resorting to outright interruption if the time didn’t come soon enough. But then I realized I’d stopped listening to the person who was talking, as my limited brainpower was focused on recalling my great idea. Today, I simply scribble the idea on a sticky note and set it aside to wai...

What are the specific things they’d do here? What are alternative things they could do? What would make it really cool? What about when things go wrong?

Focus on outcomes—what users need to do and see when the system comes out—and slice out releases that will get you those outcomes.

Don’t Prioritize Features—Prioritize Outcomes