User Story Mapping
Written by Jeff Patton
Chapters Covered 1-7
Synoposis
This book teaches the concept of user story mapping and applications. User story mapping is a technique that helps teams build better software products by creating a shared understanding of the user's needs and the product's purpose. The technique involves visualizing the product's features and user tasks in a story map, which can help teams prioritize and slice work into manageable pieces. The book covers the benefits of story mapping, how to do it, and how to use it to plan and manage software development projects. Overall, the book provides a practical and actionable guide for anyone looking to improve their product development process.
Who Should Read This Book?
I think this book is useful for product, marketing, sales and engineering. It makes you think about how to build, what to build and how to test.
TOC
Book Notes
Read This Part First
Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product. Read This First This book starts here.
- The goal of using stories isn’t to write better stories
- The goal of product development isn’t to make products
The telephone game We write lengthy documents, people read those then interpret them differently and then write other documents and tell other people
Shared documents aren’t shared understanding Shared understanding is when we both understand what the other person is imagining and why. Building shared understanding is disruptively simple
Shared Understanding
If I have an idea in my head when writing, you might get a different idea in your head when reading. If we get together you can tell me what you think and I can ask questions. Externalizing our ideas is so important.
Stop Trying To Write Perfect Documents Go write anything then use productive conversations with words and pictures to build shared understanding. The real goal of using stories is shared understanding How they should be used, not what you write down
Talking together using words and pictures
Good Documents are like vacation photos
If you look at a photo you took vs someone else’s. You know all about where and when you took that photo. Use a document to tell a story. They cant get everything from reading it
Document To Help Remember
Sticky notes, highlighting docs If a single person types what you say you’re probably doing it wrong
What’s most important is what we remember when we read it Short videos of the results of your conversations?
Talking about the right thing
Your job is not collecting and communicating requirements, its to change the world. Every great idea you turn into a product solution changes the world in some small or not so small way.
Now and Later
Requirements are just another name for the ideas we have the would help people.
They aren’t happy because of the release notes or downloaded the app, they are happy because whatever you’ve built they do things differently and that makes them happy.
Software isn’t the point
Output is easy to measure. Start to finish, number of engineers, number of features. Output isn’t the thing to measure. Outcome is what happens when things come out. Outcome is hard to measure. What do people actually do differently? Good story conversation are about who and why, not just what
OK, It’s not just about people
Not just about what makes people happy. Focus on what helps your organization earn more, protect or expand its market, or operate more efficiently. Look inside company to find people who aren’t happy They may have ideas Your company can’t get what it wants unless your customers and users get something they want.
Chowing the people to focus on, the problems to solve
Build Less There’s always more to build than we have time or resources to build - always Minimize output and maximize outcome and impact The people who choose to buy the software and choose to use. Sometimes the same More on the Dread “R” Word Figure out the least I could build to make people happy
“I need you to make these changes to the product you’re working on”
“Great, no problem. Tell me who they’re for and what problems this solves for them.” “They’re the requirements.” “I get it. Just tell me a bit about who they’re for, and how they’re going to use this, and where it fits into the way they work.” Requirements actually means shut up. They stop conversation about people and the problems we’re solving. Your job isn’t to get the requirements right. It’s to change the world.
That’s all there is to it
- Stories aren’t a written form of requirements, collab
- Discussions about solving problems for org, customers and users
- 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.
Chapter 1 The big picture
The A Word
Stories started in 2000 Telling stories, not writing stories Stories get their name from how they should be used, not what should be written Telling the whole story When you tell someone about a great idea and he says ‘yeah we do something like that too’ it’s a pattern.
Story mapping is what sensible people do to make sense of a whole product or a whole feature. Break large stories into smaller
Gary and the tragedy of the flat backlog
Gary was a businessperson launching a new web product He wrote out a prioritized list and it was taking too long
Talk and Doc
Write cards or sticky notes to externalize your thinking
Ideas vaporize - we say them and people nod and then no one writes them down. Ideas come up again and need to be re-explained
- Write down a few words about your idea immediately after thinking it
- Explain your idea as you point. Use big gestures, draw more pictures, tell stories
- Place the card where everyone can see
Scribble idea and listen
Frame your idea
Why are you building this? Tell me about the benefits for you and for the people who will use this. Purposely put the cards in the wrong order and watch the person you are working with reach out to adjust them.
Describe your customers and users
Listed different types of users and the benefits they would get why they would use the product. Never built it all. Of all these different users and the things they want to do, if we were to focus on thrilling just one of the users
Tell your users’ stories
A day in the life of someone who uses your software. Flow from left to right We’re building a shared understanding Mapping your story helps you find holes in your thinking Had to tell the story of the band manager, the fan and the venue manager Easy to get lost in the details Focus on the breadth of the story before depth
Explore details and options
Stop at each step and ask:
- What are the specific things they’d do here?
- What alternative things they could do?
- What would make it really cool?
- What about when things go wrong?
Upload an image, attach an audio file
Artgility paper. I’m not really sure what these sections mean
Art college in New Zealand
In & out not high and low.
Chapter 2 plan to build less
Globo makes the best fantasy soccer game and can’t move the deadline Many different teams but revision of ONE content management system Had to visualize dependencies
The top of the map is the backbone basic flow of the story
Big things and little things
People are doing these content management things at once but tell a narrative flow
Mapping helps you find holes
Criticism of story mapping is you end up with too much but it’s the authors belief that they are finding the stuff now that would have bitten them later on
Scope doesn’t creep -> understanding grows.
They didn’t need all of it to go live for the election
Slice out a MVP with tape Focus on outcomes - what users need to do and see
Job is not to build software it’s to change the world
They originally focused on replacing the content management system which was output instead of the outcome
Magic is in the slicing
Forum bank
Differentiator - a feature that set them apart from their competition Spoiler - a feature that is moving in on someone else’s differentiator Cost reducer - reduces organization cost Table stakes - necessary to compete in the marketplace
Some differences of opinion on table stakes vs differentiator
Definitions of MVP
Bad one - not the crappiest product you could use. MVP is the smallest product release that successfully achieves its desired outcomes Minimum viable solution is the smallest solution release that successfully achieves its desired outcomes This makes slicing a guess
What are our biggest, riskiest assumptions? Where is the uncertainty? What could I do to learn something that would replace risk or assumptions with real information?
A MVP is also the smallest thing you could create or do to prove or disprove an assumption.
Chapter 3 Plan To Learn Faster
Product owners take great ideas and run with them. Taking ownership of someone else’s idea and helping make it successful or providing it isn’t likely to be
Discussing opportunity - What is the big idea? - Who are the customers? Which companies would buy - Who are the users? Who inside those companies would use and what would they use it for - Why would they want it? What problems does it solve for customers and users that they couldn’t solve today? What benefit would they get from buying and using it? - Why are we building it? If we build this product and it’s successful how does that help us? Your first story discussion is for framing the opportunity Validate the problems you’re solving really exist Only way to know if the idea will succeed is when they see it succeed. Just a hypothesis.
Talked to customers and users
Validated there were people with the problem and were interested in buying a solution. Found that people only had poor work around to address the problems the new product idea would solve.
Customer development partners, people who will try the new software
Simple narrative stories - user scenarios.
He made a power point prototype. Did sketches Then take these proposed solutions back to the customers and celebrate any bad news because you could have received it months later
Watch out for what people say they want
He’s not sure if its minimal because if you show cool features people will say they want it. People who said they’d like and use it are also just guessing Think about stuff in your garage you’ve bought but never used
Build to learn
First goal isn’t mvp its to build something less than minimal. Just enough that users could do something useful. People may be too polite or complain even though they use it all the time. While the details his team works on release to release the backbone stays pretty consistent
Moved top row of story-mapped backlog to front of development task board/current sprint
The top slice of story has the most notes and is the most thought out.
Iterate until viable
Adding a little bit every month and getting feedback. Subjective from talking and objective with data
Each release you have something people can use. Treat every release as an experiment and be mindful of what you want to learn
Validated learning
Shipped MVP Experiment
Shipped a mvp but it wasn’t viable in the eyes of the target customers and users so it’s a mvp experiment
Product Discovery
What you are building early may not be production ready and probably shouldn’t be Used in memory databases instead of the very careful oracle db
Chapter 4 Plan to Finish on Time
Map only what you need. You can just map a feature
Backbone (simple story), prototype screenshots, details change a lot
The best estimates come from developers who really understand what they’re estimating Need shared understanding with the people building and those who envisioned it
Instead of cutting things away they know they need the whole thing this time. He’s more like a director ordering which shots but the need them all together to look like a whole
Three slices: 1. functional walking skeleton — see working end to end. Put in real data, can learn if they can scale with automated testing and find technical risks 2. Second slice to build up the functionality. Predictable unpredictable. Fine points that weren’t explored in the prototype. Things that doesn’t perform the way they expected 3. Refine, polished
Each slice isn’t a release, it’s a milestone. Take stock. By slicing things into small things, we get better at predicting.
Manage your time budget. Half way through time but only a third through building. May try to add people, cut or move deadline
Risk in the story map Skimpy budget, tight timeline, midstream leadership changes, untested technology, and tons of scope bloat Map didn’t depict the actual amount of work and learning to be done Engineering adds more stories to each detail
What would da Vinci Do?
You can’t paint the Mona Lisa bit by bit and paint more parts. Incremental strategy
Art doesn’t work this way. If you draw some animal and start on the head, then go to arms legs etc and see proportions of the animal are off.
Sketch the whole composition first.
Great art is never finished, only abandoned. - Leonardo da Vinci
Iterative AND incremental Use iterative thinking to evaluate and make changes to what you’ve already made. Use incremental thinking to make additions
- Opening game: focus on the essential features or user steps. Technically challenging or risky. Skip optional things user might do.
- Mid game: fill in and round out features. Add in stuff that supports optional steps users might take. Implement those tough business rules. You’ll be able to test end to end
- End game: refine your release. Make it sexier and more efficient to use. You’ll have feedback from users you’ll be able to apply
In this chapter, focused on a technical risk, things might blow their delivery schedule. Put the risky bits first.
Chapter 5 You already know how
- Write out your story a step at a time
- Organize your story
- Explore alternative stories
- Distill your map to make a backbone
- Slice out tasks that help you reach a specific outcome
- Left to right flow
- Fill in missing details
Alternative stories:
- Think about what you did yesterday morning. Mornings when things went wrong. Out of hot water. Think about ideal morning
- Alternatives fill in columns
- Typical, fabulous, and emergency day story.
- If you are arguing it hardly matters
Distill your kitchen, bathroom, and stuff you need to do before you leave tasks with a different color sticky note and a verb
Slice out tasks like even setting an alarm. Get out the door in a few minutes and put it on the left of the map near the top. Imagine a left to right line. Move all the tasks below that line if you wouldn’t do them to reach the goal of getting out in a few minutes. Don’t move the activities ‘Leave for 2 week vacation’ Use slices to identify all the tasks for a specific outcome
Try doing the morning mapping at work “On Fridays my wife takes the kids to school how do I represent that”
Now map and later map are the same
Try this for real Asked 3 ladies everything they did to sell custom blinds Hard to stop talking features and screens and start writing short verb phrases that say what people are really trying to do
Six steps to story mapping
- Frame the problem who is it for and why are we building
- Map the big picture breadth not depth
- Explore talk about other types of users and people
- Slice out a release strategy always too much to build. Minimum solutions
- Slice out a learning strategy
- Slice out a development strategy
Key good practices
- First time a team does it use an experienced coach
- Starting with high level usage steps
- Finer activities per user role
- Concrete user stories as a <> I want <> so that <>