More on this book
Community
Kindle Notes & Highlights
by
Jeff Patton
Read between
June 14 - July 23, 2015
Perhaps the biggest disappointment for me in the decade of the adoption of Agile methods is the way that many programmers see stories as a one-way communication from analysts to them.
The goal of using stories isn’t to write better stories. The goal of product development isn’t to make products.
Shared documents aren’t shared understanding.
The talking goes better if we can externalize our thinking by drawing pictures or organizing our ideas using index cards or sticky notes.
The real goal of using stories is shared understanding.
Stories in Agile development get their name from how they should be used, not what you write down.
It was at that moment that I learned that the word requirements actually means shut up.
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.
Talk and doc: write cards or sticky notes to externalize your thinking as you tell stories.
There’s always more to build than you have people, time, or money for. Always.
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.
A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption.
Map only what you need to support your conversation.
Tasks are short verb phrases that describe what people do. Tasks have different goal levels. Tasks in a map are arranged in a left-to-right narrative flow. The depth of a map contains variations and alternative tasks. Tasks are organized by activities across the top of the map. Activities form the backbone of the map. You can slice the map to identify the tasks you’ll need to reach a specific outcome.
Use storytelling with words and pictures to build shared understanding. Don’t just talk about what to build: talk about who will use it and why so you can minimize output and maximize outcome.
We can both read the same document, but have a different understanding of it.
The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.
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.
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.
When I walk into environments where the walls are clear, or even covered with pleasant artwork—or worst of all, motivational posters—it makes me sad.
Handing off all the details about the story to someone else to build doesn’t work. Don’t do that.
Effective discussion and decision making goes best with small groups of two to five.
Validated learning over working software (or comprehensive documentation)
There’s a nasty misassumption in common Agile practice: that there’s a single person responsible for writing stories and conducting all these story conversations.
Requiring a single product owner to write all of the stories and be present for all story conversations doesn’t work.
If the only thing you create while making sense of a big, ambiguous opportunity is smaller stories, then you’re probably doing it wrong.
If you’re not cutting away more ideas than you keep, you’re probably not doing discovery work right.
Talk directly to customers and users. Experience the challenges you’re helping them with firsthand.
