Rock Breaking

Definition

Patton's central metaphor for splitting work: hit a big rock with a mallet and you get smaller rocks, hit one of those and you get smaller ones still — "at every size, no matter how small, they're still a story," and deliberately fuzzy about exactly when a "boulder" becomes a plain "rock." He resists giving the sizes precise names (epic for a big story, theme for a bag of related stories) because the imprecision is a feature: it lets the same lightweight tool — talking it through — work at every scale, from a whole product down to a single line of code. The tool that breaks rocks is conversation: "conversations are one of the best tools for breaking down big stories."

In the Book

Chapter 11 lays out the full rock-breaking lifecycle as three staged commitments, each cheaper to reverse than the last. It starts with an opportunity backlog — named ideas that haven't been vetted — and a first, higher-level "who-what-why" conversation whose only goal is a go-forward/trash decision: "no is a polite way of saying trash," and killing a mediocre opportunity early "should be celebrated" rather than treated as failure. A "go" opportunity then moves into discovery, where the team digs into who the users are, how they work today without the solution, and validates assumptions through prototypes and spikes (a term from Extreme Programming for research work whose explicit goal is learning, not shippable code) — the output is a minimum viable solution, "separating precious metals from rock." Only stories that survive discovery move into delivery, where deep-dive conversations with developers and testers break them down further into pieces small enough to build and learn from in a single cycle. Patton is explicit that epic and theme are borrowed, imprecise labels used mainly because Agile tooling expects them — the real discipline is the staged sequence of conversations, not the vocabulary.

Why It Matters

Treating decomposition as a single pass — break the big idea into build-ready tasks all at once — collapses distinct kinds of risk (is this worth doing at all? do we know what to build? can we build it well?) into one conversation, which either takes forever or skips steps. Splitting into progressively cheaper, progressively more committed stages — screen for worth, then validate the solution, then plan execution — lets you kill bad ideas before paying discovery costs, and kill bad solutions before paying build costs. The same staging shows up anywhere a big commitment is de-risked by resolving cheaper uncertainties first: research funding, capital allocation, hiring pipelines.