It’s entirely reasonable that programmers build software one feature at a time. That’s a perfectly good strategy, proven over the years. What has also been proven over the years is that, when used as a method for designing the behavior and scope of a digital product, one-feature-at-a-time yields a Frankenstein monster of a program.
The challenge we face is creating big software that people love. Big software serves large audiences doing complex, commercially viable jobs. It’s ridiculously hard to make such software fun to use and easy to learn.
Shared documents aren’t shared understanding.
Stop trying to write the perfect document. Go ahead and write something, anything. Then use productive conversations with words and pictures to build shared understanding.
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.[
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.
Stories get their name from how they should be used, not what should be written.
As we talk and doc, and as I write down our conversation, we’re building something really important. No, it’s not that pile of cards on the floor. The something that’s really important is shared understanding.
You’ll find that no matter how clear you are about your story, talking through it while you map will help you discover the holes in your own thinking.
Another mantra I use when mapping, at least at this stage, is “think mile wide, inch deep”—or for people in sane countries using the metric system: “kilometer wide, centimeter deep.” Get to the end of the story before getting lost in the details.
There’s always more to build than you have people, time, or money for. Always.
Scope doesn’t creep; understanding grows.
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.
Focusing on specific target outcomes is the secret to prioritizing development work.
Be specific about who your customers and users are, and what they need to accomplish. What’s minimum to them?
A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption.
Use the goal-level concept to help you aggregate small tasks or decompose large tasks.
Maps are organized left-to-right using a narrative flow: the order in which you’d tell the story.
Details, alternatives, variations, and exceptions fill in the body of a map.
If you’re arguing, it likely means that it doesn’t matter. For instance, putting breakfast before or after taking a shower is a matter of preference. Go with what’s most common for the group you’re working with.
Activities and high-level tasks form the backbone of a story map.
You can learn even more if you go back and add other things to the map. The easy things to add are: 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