More on this book
Community
Kindle Notes & Highlights
by
Jeff Patton
Read between
March 1 - March 28, 2022
Your company can’t get what it wants unless your customers and users get something they want.
There’s always more to build than we have time or resources to build—always.
Minimize output, and maximize outcome and impact.
For a great many people, that’s exactly what requirements do. They stop conversations about people and the problems we’re solving. The truth is, if you build a fraction of what’s required you can still make people very happy.[3] Remember: at the end of the day, your job isn’t to get the requirements right—your job is to change the world.
Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding.
Roxana Soporan liked this
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.
Stories get their name from how they should be used, not what should be written.
Story maps are for breaking down big stories as you tell them.
Talk and doc: write cards or sticky notes to externalize your thinking as you tell stories.
Focus on the breadth of the story before diving into the depth.
There’s always more to build than you have people, time, or money for. Always.
Map for a product release across multiple teams to visualize dependencies.
Scope doesn’t creep; understanding grows.
Focus on what you hope will happen outside the system to make decisions about what’s inside the system.
Focusing on specific target outcomes is the secret to prioritizing development work.
behind outcomes are specific behavior changes for specific people engaged in specific activities.
Differentiator A feature that set them apart from their competition Spoiler A feature that is moving in on someone else’s differentiator Cost reducer A feature that reduces the organization costs Table stakes A feature necessary to compete in the marketplace
I commonly see organizations rationalizing their bad product decisions with the argument that someone could use the product, when it’s clear to everyone involved that they probably wouldn’t choose to.
The minimum viable product is the smallest product release that successfully achieves its desired outcomes.
The minimum viable solution is the smallest solution release that successfully achieves its desired outcomes.
Some of the most important things you can discuss during story and story map conversations are: What are our biggest, riskiest assumptions? Where is the uncertainty? What could I do to learn something that would replace risks or assumptions with real information?
A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption.
If you don’t get beer, or an equivalent reward, for solving tough problems where you work, you should have a talk with someone about that.
Map only what you need to support your conversation.
Dont waste time building out a map for everything!
The best estimates come from developers who really understand what they’re estimating.
Great art is never finished, only abandoned. — Leonardo da Vinci
User tasks are the basic building blocks of a story map.
A sea-level task is one we’d expect to complete before intentionally stopping to do something else.
Activities organize a bunch of tasks done by similar people at similar times in order to reach a particular goal.
Pains Things that don’t work, parts people hate Joys or rewards The fun things, the things that make it worth doing Questions Why do people do this? What’s going on when they do? Ideas Things people could do, or that we could build that would take away pain, or make the joys even better
If we get together and talk about the problem we’re solving with software, who’ll use it, and why, then together we can arrive at a solution, and build shared understanding along the way.
If you’re not getting together to have rich discussions about your stories, then you’re not really using stories.
“I hate that term backlog. We haven’t even started to build software, and it already sounds like we’re behind!”
Story conversations are about working together to arrive at a best solution to a problem we both understand.
Template Zombie: The project team allows its work to be driven by templates instead of by the thought process necessary to deliver products.
the real value of stories isn’t what’s written down on the card. It comes from what we learn when we tell the story.
There are many different kinds of conversations with different people for every story.
“meeting” is often the euphemism we use for unproductive collaboration.
If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal.
If the story describes a solution that’s affordable but big, break it into smaller parts that allow you to evaluate and see progress sooner.
Don’t break down big things into big plans. Break big things into small things with small plans.
you can deliver “half a baked cake, not a half-baked cake.”
A right-sized story from a development team’s perspective is one that takes just a few days to build and test.
An epic is a story that we expect is large, and know needs to be broken down.
Use opportunity discussions to agree the problem is worth solving—to make a go-forward or trash decision.
