INVEST Model

There's an item at the top of the backlog that everyone's been avoiding. It's too big, too vague, and nobody can estimate it. It's about to land in the next sprint anyway.

INVEST is Bill Wake's mnemonic for well-formed user stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable. You run each story through the six criteria during backlog refinement, catching problems before they enter a sprint.

The unique strength is giving teams a shared quality gate that's fast to apply and hard to argue with. Stories that fail INVEST cause predictable damage — dependencies create blocking, vague requirements prevent estimation, and oversized items blow up sprint commitments.

The 'Small' criterion trips most teams up; they habitually write epics and label them stories. It falls apart when over-applied as a rigid checklist to every item, including spikes and technical work that don't fit the user-story shape.

Your next move: Which 'story' at the top of your backlog is actually an epic that nobody has bothered to break down — and how predictable will the next sprint be when it lands intact?

What it looked like for them

Pierre-Olivier Latour, Everpix, 2012–2013. Everpix's team faced a compounding infrastructure crisis: four hundred million photos hosted, AWS costs growing faster than revenue, and a product roadmap that mixed critical survival work with aspirational features.

The work was never broken into pieces that could be evaluated independently. Infrastructure fixes, growth features, and speculative experiments were tangled together in the same backlog, estimated in the same way, and prioritised by whoever argued loudest. Nothing was small enough to ship and learn from quickly.

Nothing was independent enough to defer without blocking something else. The INVEST criteria — Independent, Negotiable, Valuable, Estimable, Small, Testable — describe exactly what Everpix's work items weren't. A thirty-five-thousand-dollar AWS bill came due that the team couldn't pay.

By the time the work had been broken down enough to triage, there was nothing left to triage with. The inability to decompose work into manageable increments didn't cause the failure. It prevented the team from seeing the failure coming in time to act.