Story as Conversation, Not Document

Definition

Patton traces the term "story" to Kent Beck, who wanted teams to talk about what software should do the way users later tell stories about cool things it does — not to write more precise specification documents. Ron Jeffries' "3 Cs" formalize the mechanism: Card (a short title, just enough to remember what to discuss), Conversation (the people who understand the problem and the people who can solve it talk it through together), and Confirmation (agreeing together what you'll check to know it's done). "Stories get their name from how they should be used, not what should be written."

In the Book

Chapter 6 opens with the failure mode this replaces: teams writing exhaustive requirements documents that different readers interpret differently, and that "often accurately describe the wrong thing" because they capture what to build but not why. Kent Beck's fix, recounted from a personal email exchange with Patton, was disarmingly simple — get people together to talk, the way a user later recounts "if I type in the zip code, it automatically fills in the city." Chapter 7 traces how this got lost almost immediately: teams that inherited the story idea kept their old requirements-document mindset and just tried to write more precise story cards, which Patton calls the most common failure — "if you're not getting together to have rich discussions about your stories, then you're not really using stories." He grounds the Connextra template ("As a [user], I want to [goal], so that [benefit]," from Rachel Davies' team at Connextra, one of the earliest Extreme Programming adopters) not as a writing formula but as a forcing function to pause and ask who/what/why before a conversation, because salespeople writing pure feature titles gave developers nothing to start a discussion from. Chapter 9 states the anti-pattern directly: "handing off all the details about the story to someone else to build doesn't work" — a document always looks complete to its author, because the author's brain silently fills every gap that isn't written down, gaps invisible to anyone who wasn't in the room.

Why It Matters

Any artifact meant to transfer understanding between people — a spec, a brief, a design doc, a policy memo — carries only what was written, while the author's head carries everything that wasn't. Treating the artifact as a prompt for a conversation, rather than a self-sufficient deliverable, catches the gaps a document alone would hide, because a listener who can ask "what did you mean by that" surfaces the missing context that a silent reader cannot. This generalizes past software to any handoff where tacit knowledge outweighs what fits on the page.