Quotes from Jeff Patton

Stories are the building blocks of communication between developers and those who use their work. Story maps organize and structure these building blocks, and thus enhance this communication process — which is the most critical part of software development itself.

be prepared for surprises and bad news. In fact, celebrate the bad news, because you could have received the same bad news months later, after you'd built the software.

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.

Documents usually describe what we need, but not why we need it.

Right now you should stop whatever you're doing and say this out loud: Stories get their name from how they're supposed to be used, not from what you're trying to write down.

Interaction design is all about finding the user's truth and telling it as a narrative. Software development is all about breaking those narratives into tiny, functional chunks and implementing and integrating them.

Handing off all the details about the story to someone else to build doesn't work. Don't do that.

Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product.

Stories get their name from how they should be used, not what should be written.

Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries.

Great art is never finished, only abandoned.

Ben Horowitz's Good Product Manager, Bad Product Manager,

Try showing up at your doctor's office and giving her your "requirements." Tell her the prescriptions you'd like written and the operations you'd like scheduled. If she's nice, she'll smile and say, "That's interesting; tell me where it hurts.

Remember: at the end of the day, your job isn't to get the requirements right — your job is to change the world.

Try to make your working relationships much more like a good doctor-patient relationship, and much less like a waiter-diner's.

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.

A sea-level task is one we'd expect to complete before intentionally stopping to do something else.

Use the goal-level concept to help you aggregate small tasks or decompose large tasks.

Stories get their name not from how they're supposed to be written, but from how they're supposed to be used.

If you're not getting together to have rich discussions about your stories, then you're not really using stories.

Template Zombie: The project team allows its work to be driven by templates instead of by the thought process necessary to deliver products.

Focusing on specific target outcomes is the secret to prioritizing development work.

we need to acknowledge that building software isn't the same as working on an assembly line. You're not just building one more widget like the one you built a few minutes ago. Each new story we create software to support is something new.

And, of course, as savvy readers can appreciate, when software developers say it's going to take a year to get something done, they really mean two years. It's not because they're incompetent, or that they are calendar-challenged, it's just that estimating the time to do something we've never done before is something we suck at. And, by nature, we're often optimistic animals.