“User Story Mapping: Discover the Whole Story, Build the Right Product” by Jeff Patton, Peter Economy
eBay Velocity Initiative Sprint planning
Review
The general idea here is that we think through a goal by identifying the steps to accomplish that goal from a user’s perspective. From there, we break those steps down into individual details which will eventually decompose into stories.
Those stories are ranked on an approximate release order using the grouping of “see it work” -> “make it better” -> “make it releasable”. There will inevitably be things that would make it even better, but we only have a limited amount of time. The goal in this process is figuring out how we can minimize output (e.g. not do too much) and maximizing outcome (e.g. getting lots of happy customers)
One of their positions, which I hadn’t heard described this way, is that stories aren’t for holding requirements. The way we uncover things in a story is with conversations between folks. Stories are closer to vacation photos. When you see your vacation photo, you remember all of the great context. For everyone else, they’re way flatter and less impressive.
Our cards should have two important pieces, that I’ve not seen much of here. First, it should have acceptance criteria. If we build what we’re agreeing to.. what will we check to validate we’re done? Second, when we go to demo this.. how will we demo it? (This will likely catch a few missing acceptance criteria).
Lastly, they talked about story sizing (e.g. epics vs stories vs tasks). They use the analogy of a rock. If you take a rock, and break it up into smaller bits.. it’s still a rock. You just have more of them. The same is true with stories. The size that’s appropriate for one group (product) is likely not the same as those working on it (devs). “The size of the rock (story) only matters when it’s being thrown at you”, was a good quote which helped me cement the “let the product people have their massive stories until it’s time for breaking them down” idea. How much the story is broken down depends how close to being implemented it is. By the time it gets into a dev’s todo list.. it should hopefully be broken down into a 1-2 day effort thing.
Conclusions
The big takeaway I had was that we’re not doing enough small iteration. We’re building what appears to be a lot of fully-developed solutions, rather than small things that we successively validate.
Useful diagrams
This is the process that the book recommends. The “backbone” are steps a user (or possibly system) takes. Details go vertically. Some details get kicked out to a future
Raw notes
Chapter 1
The whole point of user stories is that they serve as a genesis & eventual collection point of conversations about the problem and how we might solve it.
In this image, “oh..” and “ah ha!” are the conversation & talking through acceptance criteria.
“document [stories] to help remember”
He talks a little bit about documents and how it’s like vacation photos. When you see your vacation photo, you have a lot of surrounding context and memory that they bring to the surface. When other people see them, they just see the photo which isn’t that impressive.
- Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding.
- Stories aren’t the requirements; they’re discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build.
- 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.
I first heard this definition of a pattern from my friend Linda Rising: when you tell someone about a great idea and he says, “Yeah, we do something like that, too.” It’s not an invention, it’s a pattern.
He seems to be a big advocate of index cards to externalize thought processes so you can, for instance, rearrange them. I’m not clear how this works in a remote world.
He has a specific order for the cards like this:
[thing people will use software for]
[step 1][step 2][step 3] [step 4]
[details]
[of the]
[step if]
[needed]
[go vertically]
[on cards]Questions for each step:
- 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?
instead of must-have vs should-have vs could-have.. they have a simple in or out. In = “We cannot possibly go live without this”
Chapter 2
Scope doesn’t creep; understanding grows.
He talks a bit about mapping to outcomes, not deliverables. In particular, it’s good to acknowledge that you’re going to please some folks with a particular release, but not everyone. Subsequent releases can fix that. These subsequent releases build up a “release roadmap”. This isn’t a feature list, but rather a list of outcomes e.g. real-world narratives that customers can do.
A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption.
“customer development partners” are the users you use to iterate w/ like alpha folks.
Chapter 4
To build this new feature, these two guys will need to build shared understanding with their team. Their team needs to be able to point out problems and possibilities for improvement, and to estimate how long it’s going to take. That’s what they built this final map for. They used it to tell the feature’s story—step by step, from the user’s perspective.
There are lots of methods that promise to give more accurate estimates. I’m not going to cover any of those here. But I will tell you none of them work if the people building the software don’t have shared understanding with one another, and with those who envisioned it.
“functional walking skeleton”: the barest of prototypes so you can see the end to end flow (via Alistair Cockburn)
Along the way, they’re likely to learn some things they couldn’t predict. They may have overlooked some characteristics this feature should have—finer points that weren’t explored in the prototype. They may have found that the system just doesn’t perform the way they expected and some extra work will need to be done to get the speed they want out of it. These are the “predictably unpredictables”—a concept closely related to Donald Rumsfeld’s “unknown unknowns.” Don’t pretend they don’t exist. You know they do.
By slicing large things into small things, we get more opportunities to measure. Of course, there’s some subtlety to this, but as a general principle, you’ll get better predictions if you’ve got more examples of how long similar things have taken to build.
Chapter 5
Don’t just talk about what to build: talk about who will use it and why so you can minimize output and maximize outcome
^^ This is basically why PRFAQ style writing works.
Six steps to story mapping:
While I know there are lots of right ways to build up and use a story map, I have found that the following six-step process works well for me:
- Frame the problem. Who is it for, and why are we building it?
- Map the big picture. Focus on breadth, not depth. Go a mile wide and an inch deep (or a kilometer wide and a centimeter deep, for my friends in the rest of the world). If you don’t have a clear solution in mind, or even if you think you do, try mapping the world as it is today, including pains and joys your users have.
- Explore. Go deep and talk about other types of users and people, how else they might do things, and the kinds of things that can (and likely will) go wrong. For extra credit, sketch, prototype, test, and refine solution ideas—changing and refining the map as you go.
- Slice out a release strategy. Remember: there’s always too much to build. Focus on what you’re trying to achieve for your business, and on the people your product will serve. Slice away what’s not needed to reveal minimum solutions that both delight people and help your organization reach its goals.
- Slice out a learning strategy. You may have identified what you think is a minimum viable solution, but remember that it’s a hypothesis until you prove otherwise. Use the map and discussion to help you find your biggest risks. Slice the map into even smaller minimum viable product experiments that you can place in front of a subset of your users to learn what’s really valuable to them.
- 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 help you learn to spot technical issues and development risks sooner.
Chapter 6
Kent Beck, person behind the notion of “user stories” on what they’re for.
What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does. [For example,] if I type in the zip code and it automatically fills in the city and state without me having to touch a button.
I think that was the example that triggered the idea. If you can tell stories about what the software does and generate interest and vision in the listener’s mind, then why not tell stories before the software does it?
— Kent Beck via personal email, Aug 2010
He talks about how to organize stories, based on info from “Extreme Programming Installed” by Ron Jeffries:
- Write cards for what is is the user will see.
- Talk about it. This involves back and forth with the people who will be doing the work.
- Get some “confirmation” about what you’re going to build.
Confirmation is:
- If we build what we agree to, what will we check to see that we’re done?
- When we go to demo this.. how will we demo it? (This likely adds a thing or two to your acceptance criteria)
Chapter 7
Given the story: “As a band manager, I want to upload an image so that I can customize my promo flyer.” Here’s an example conversation: “Why would the band manager want to customize the flyer?”
“Well, because it won’t have his band’s photo on it automatically, and he’d want it to be there. And he cares a lot about being original—he wouldn’t want it to look like everyone else’s.”
“That makes sense. Where do people like band managers keep those photos?”
“Well, they’re all over the place, really. They may be on their local hard drives, in Flickr accounts, or in other places on the Web.”
“Hmm…that’s different than I was originally thinking. I assumed they’d just be on their hard drives.”
“No, lots of the people we’ve talked to have them spread all over the place. It’s kind of a problem.”
Note that this is quite different than what I’ve seen internally w/ us having more fully-baked feature lists and very little conversation.
Stories are really about having a conversation with your product owner. At the end, you’re hoping to record those conversations in a “vacation photo”.
Chapter 8
Stories have:
- title
- description (who what why)
- size
- metrics to monitor?
- dependencies?
Chapter 9
In a traditional process, learning gets referred to as scope creep or bad requirements. In an Agile process, learning is the purpose.
Chapter 11
A right-sized story from a development team’s perspective is one that takes just a few days to build and test.
A right-sized story from a business perspective is one that helps a business achieve a business outcome.
^^ Though note that you can potentially scope it to solve a smaller sub-section of the user-base and it can still hit this qualification.
I really like their notion of treating stories like “rocks”. If you smash the rock, you get more pieces. Those are called rocks too. So too can a story can be at multiple sizes and still be a story.
~“The size of the rock(story) only matters when it’s being thrown at you”. e.g. developers will want smaller stories and that’s a good thing for them.
An epic is a story that we expect is large, and know needs to be broken down.
Chapter 17
Talks about how stories are like asteroids, the game. Big rocks move slow. If you break them into smaller rocks, they move fast. If you have too many fast-moving rocks.. that’s dangerous. So too, you should be keeping large, un-brokendown stories until you’re ready to work on them. This way, your backlog can stay small and useful.
When breaking down stories, consider this, depending on phase:
- opportunities: who they’re for, what problem they solve, if they’re aligned with business strategy
- discovery: discuss specifics of use. Envision a product that’s valuable, usable & feasibile to build. (This seems applicable to the “minimize output, maximize outcome/impact” philosophy from earlier)
- dev strategy: What are the risks? Break out a few “learning stories” to de-risk it.
- dev cycle planning: exactly what to build & how to check the software to confirm it’s done.
Chapter 18
Receipe for review/reflection
- Product quality? UX/Functional/Technical
- During demo/retro, reflect on the UX, functional and code-side of the features we released.
- create stories, if necessary, to improve/change the product based on ^^
- Plan
- If you had a time-box iteration, were your predictions good ones?
- Get a sense of overhang/hangover.. the amount of undone work at the end of the iteration
- Process
- Discuss the changes you tried last cycle. Did they work? Continue or stop trying it?
- Discuss changes to try for the next cycle. Don’t take on too much.