User Story Mapping Talk

This is first blog post where I’m publishing notes from a conference talk that I’ve watched. It’s mainly for me that I can in future find these more easily. But it might be useful for others too.

I’m summarizing this time Jeff Patton’s User Story Mapping talk.

“Our job is not to build software, it’s to change the world.”

Stories are meant to solve 2 problems in software development

1. Documents don’t work (Use storytelling to build shared understanding)
2. Too much to build (Minimize output – understand who, what, why!)

Kent Beck’s idea:

“Stop it. Stop exchanging documents. Tell me your story.”

1. Use the card for facilitating a conversation
2. Shared documents aren’t shared understanding

Stories help people remember things that weren’t written on the document. The best documents use words and pictures to help recall our conversations, they don’t replace conversations. Stories are an antidote to “requirements”.

Most challenging problem is not what to build next, it’s who to pay attention to.

Rachel Davies was struggling at Connextra (late 1990’s) with feature ideas on cards. It was hard to figure out who had written them and what they were about. Very often when Rachel discussed about ‘Who, What & Why’ related to idea with a person herself, it turned out that the feature wasn’t needed afterall.

Therefore, Rachel and her team decided to create story card template that required people to put a bit more thinking BEFORE writing a feature suggestion.

Stories aren’t a different way to write requirements, they’re a different way to work.

Story Mapping A story map is a simple way to tell a story and break it down into parts.

Use story maps to understand your whole product or feature’s experience. Use mapping to break down big stories without losing the big picture.

Instead of prioritizing stories, prioritize outcomes. Slices of outcomes form delivery strategy that is aiming at maximizing learning.

1. Change the way you work: tell stories, don’t just write them
2. Use simple visualizations to anchor the stories you tell
3. Map the whole story to find the parts that matter most
4. Think things through: minimize output, maximize outcome and impact
5. Build minimum viable product tests to find what’s minimum and viable in market
6. Build your product up iteratively and incrementally

Story mapping helps in having the conversation about the stories.

What to build Harvard Business Review article: The Big Lie of Strategic Planning

1. Where you’ll play (target market, customers)
2. How you’ll win (how is it better, how will it help)

Strategic refers to risk, guess, gamble and bet

Stories are too big Card (story itself) Conversation (discuss e.g. in backlog refinement in front of whiteboard) Confirmation (How do we know we succeeded?)

Splitting the stories into smaller is the responsibility of the people who are having the discussion (e.g. PO, UX, Dev, Tester).

Shared understanding when not collocated

1. Utilizing for example Google Docs, Mural.ly, cardboardit.com, stormboard.com, Ipevo
2. Asking people to reply how they understood something

There’s was a great example of team creating a story map and leaving the backbone on the wall and ripping rest of the notes of the wall. Then they would create the story map couple times again. This way everyone got good understanding of overall solution when it was created several times and people had to focus on whole flow instead of only what they were going to be working with later on.