If I had to define agility in a single sentence, it would be this: the ability to change direction quickly and cheaply. Everything else agile teams do is in service of keeping that ability alive. And almost nothing kills it faster than large stories.

Why big stories hurt#

Imagine the requirements shift halfway through a large story. You're now stuck choosing among three bad options:

• Discard the finished work, throwing away effort you've already spent.
• Finish something already obsolete, just to call it done.
• Rework it, paying to partially undo and rebuild what you have.

Every one of those options is painful, and the bigger the story, the more painful each becomes. Small stories don't eliminate the choice, but they shrink the cost of all three branches. Tossing out a day's work stings far less than tossing out two weeks.

The agile principles small stories unlock#

Two principles I care about depend directly on keeping stories small.

The first is welcoming change, even late in development. You can only welcome a late change if absorbing it is cheap. Large stories make late changes feel like sabotage, which is exactly why teams carrying them grow defensive about scope.

The second is delivering working software frequently. Small stories are the unit that makes frequent delivery possible. A pile of half-finished large stories produces nothing shippable; a steady stream of small completed ones produces a constant flow of value.

Large stories also quietly drag in extra risk and uncertainty. The more a single story tries to accomplish, the higher the odds it gets blocked or stalled partway through, which undermines the steady, sustainable pace that healthy teams rely on.

Defining "small" concretely#

"Small" is uselessly vague unless you anchor it. The definition I use is: the smallest increment of value that can sensibly be worked next. Not the smallest technical task, and not a fragment with no user-facing value, but the thinnest meaningful slice. It also helps enormously to pick a reference story everyone agrees is genuinely small, and to size new work against it.

A four-question split test#

When I'm deciding whether a story needs splitting, I ask four questions:

1. Is the increment of value large?
2. Is the complexity high?
3. Is completion risky?
4. Is there significant uncertainty?

A "yes" to any one of these is my signal to thin-slice the story into something smaller. I don't need all four to fire; one is enough.

Sizing scales that reinforce smallness#

Two scales work well in practice. A Fibonacci scale (1, 2, 3, 5, 8) is common, and I reserve 1 for the smallest stories. The useful insight is that the higher the number, the less agile that story makes you, because you've packed more risk and effort into a single unit.

A simpler 1/3/5 scale also works nicely: 1 is the smallest thing worth doing, 3 is moderate, and 5 means "too big, must split." The exact numbers matter less than the discipline of treating large estimates as a prompt to break work down.

The four dimensions of size#

It's worth remembering that "size" isn't one thing. A story's size is really a blend of four dimensions: effort, complexity, risk, and uncertainty. A story can be small in effort yet enormous in uncertainty, and that uncertainty alone can justify slicing it thinner. Keeping all four in mind stops you from mistaking "few hours of typing" for "small story." The smallest stories are small across all four, and those are the ones that keep your team genuinely able to turn on a dime.