INVEST Criteria for Better User Stories

The teams who can recite the six letters fastest still carry stories that have rolled over four sprints in a row, and that isn't a memory problem. INVEST is used as a grading rubric on stories already written, when its real power is as a diagnostic on stories already failing — and the letters aren't a flat list. They're a causal chain, and one of them isn't a criterion at all.

Bill Wake published INVEST in 2003 as a way to check whether a story was any good (XP123). Independent, Negotiable, Valuable, Estimable, Small, Testable. Twenty-odd years later it's on refinement templates, in Jira fields, and printed on team-room walls — and teams with it on the wall still carry stories that will not move.

The criteria aren't wrong. They're run at the wrong moment, in the wrong order, against the wrong question. For the format itself — the "as a / I want / so that" shape and what belongs in acceptance criteria — see User Story Template: INVEST in Plain English. This piece is the other job: a story has been in progress three weeks, everyone is frustrated, and you need to know which letter is actually broken.

Why the checklist runs too late

INVEST-as-checklist gets applied at the end of refinement, by the person who just wrote the story, to the story they just wrote. That is self-grading, and self-grading has a predictable result: everything passes.

Think about how the session runs. Someone reads the story. "Independent?" — "should be." "Valuable?" — "the customer asked for it." "Estimable?" — "let's point it." The story is five minutes old and its author is in the room. Nobody in that configuration discovers that the story contains four stories, because discovering that costs another forty minutes and nothing has gone wrong yet.

Something has to go wrong first. The criteria earn their keep on the other side of the sprint — on a story that has visibly failed to move — where the evidence is sitting right there and a pass is no longer theoretical.

Run this today: pull the three oldest items in your In Progress column and note days-in-progress against your sprint length. Those are your specimens. Everything below is applied to them, not to whatever you're about to write next.

The letters are a chain, not a list

Presented as an acronym, the six letters look like six independent gates of equal weight. They aren't. They sit in a causal order, and running them out of order is why teams spend refinement arguing about the wrong thing.

The order that works:

1. Valuable — is there a point? If nobody is worse off when this doesn't ship, the story doesn't need splitting or estimating. It needs killing.

2. Testable — would we know it worked? A story you can't observe passing isn't a story; it's a wish with a ticket number.

3. Independent — can it move alone? Can it reach a user without another ticket merging first?

4. Small — can it finish inside one sprint, with room to be wrong once?

5. Estimable — not a criterion. A readout. More below, because it's where most diagnoses go wrong.

6. Negotiable — this one describes a relationship, not the story. It fails when the story arrives from outside as a fixed spec nobody in the room may change. Check it once per team, not once per story.

Wake said as much about the coupling: "Being estimable is partly a function of being negotiated, as it's hard to estimate a story we don't understand." Estimability is downstream of nearly everything else, which is exactly why it's the least useful place to start.

Run this today: take one stuck story and write the six letters down the margin. Work top to bottom in this order and mark each pass or break with a one-line reason. Stop at the first genuine break. That's your disease; the rest are symptoms.

Walking one story down the chain

The following is a labeled illustrative composite, drawn from patterns common in B2B SaaS identity work. The figures are illustrative, not measured.

A logistics-software team had a story on the board called SSO-14: As an enterprise admin, I want my team to sign in with our company identity provider, so that we stop managing separate passwords. It had been pulled into four consecutive sprints. Each sprint it moved to In Progress, accumulated commits, and moved back. The retro answer never changed: "we couldn't size it properly."

So the team did the obvious thing, which is the thing that doesn't work. They tried to make it more estimable — more detail in the description, a spike to "investigate SSO," a longer refinement session. Sprint five, it rolled again.

Run the chain instead.

Valuable — pass. Two named deals had SSO on their security questionnaire, both marked blocker. Someone is worse off on the day this doesn't ship and you can name them. Rule it out. (This letter fails most often on internal platform work, where the value is real but the user is another engineer — if that's your pattern, the story shape is wrong rather than the story, and Job Stories: An Alternative to User Stories is the usual escape hatch.)

Testable — pass, at first look. Could someone write the failing observation? Yes: an admin clicks Sign in with SSO, authenticates at their provider, lands on the dashboard as themselves. A real criterion, not a feeling. Hold this one loosely, though — it comes back.

Independent — partial break, not the disease. SSO-14 needed a session-handling change in another ticket. Real, but bounded: one dependency, one team, merged by sprint two. If that were the disease, the story would have unblocked in sprint three. It didn't.

Small — break. Here's the artifact that proved it, which cost eleven minutes to produce.

SSO-14 had been estimated three times. Rather than estimate a fourth, the team looked at the spread of the previous rounds — 5, 8, 5, 21, 40, 13 — and the facilitator asked the question that actually diagnoses this: "Say out loud what you were sizing."

The 5s and 8s were sizing "wire up OIDC against one identity provider for one pilot tenant." The 21 and the 40 were sizing "SSO across the four identity providers our enterprise customers actually use, plus just-in-time provisioning, plus deciding what happens to the 1,200 existing password accounts on those email domains."

Those are not different estimates. They are estimates of different stories, and the room had been averaging them for four sprints. The disagreement had already done the splitting; nobody had written it down.

SSO-14 became four stories, sliced vertically the way Wake describes — each a thin slice through the whole cake rather than a layer of it. One pilot provider end to end. Additional providers. Just-in-time provisioning. Account linking for existing users.

The second pass, and the question nobody asked

Three of those four shipped in the next two sprints. The fourth — account linking — rolled over again.

Splitting is where most teams stop, and splitting alone did not fix this. Run the chain again on the child and the break lands somewhere else.

Testable — break. Nobody could state the failing observation. What is correct when a user signs in via SSO as j.reyes@acme.com and there is already a password account for jreyes@acme-logistics.com that owns three years of shipment history and is the billing contact? Merge? Create a second account? Ask the user? Ask the admin? Every answer had an advocate and an objection, and the argument had run three times without producing a criterion.

That is not an engineering disagreement. It's an unanswered discovery question about identity data that everyone had been treating as an implementation detail — and no amount of story-writing craft closes that gap.

The discovery move is a query, not a meeting. The question that broke it open: "How many existing accounts would actually hit the ambiguous case — and can we look rather than argue?"

Somebody ran it. Of the 1,200 password accounts on those customer domains, 1,153 matched their corporate identity exactly. Forty-seven did not.

Forty-seven changes the shape of the decision. An automatic merge policy that must be correct across 1,200 unknown cases is a genuinely hard design problem. Forty-seven rows is a spreadsheet and an afternoon of customer-success work. The team shipped exact-match automatic linking and routed the 47 to a one-time reconciliation list with a named owner. The story became estimable — 8 points, unanimous — because it became small, and it became small because a query replaced a policy argument.

That's the pattern underneath the method: an untestable story is usually a data question wearing an engineering costume, and the way out is to count the thing everyone is speculating about. The general form of that move is Requirements Elicitation Techniques That Work.

Run this today: on your most-argued-about story, find the one claim in the argument that is a countable fact about your existing data, and count it before the next refinement session. Bring the number instead of the opinion.

The symptom table

The diagnosis is easier when you work backwards from what you actually observe. You never observe "this story is not Independent." You observe that it finished and nothing shipped.

Symptom you actually observe	Letter that's failing	The test that confirms it	The move
Estimates spread more than about 3× across the room	Small	Ask each estimator to say aloud what they were sizing; count the distinct scopes	Split along the scopes people named — the disagreement already did the splitting
Story is "done" but nothing is visible to a user	Independent	Trace which other ticket must merge before a user sees anything	Sequence deliberately and name the release unit, or fold the dependency in
Nobody can say what "done" looks like without naming a person	Testable	Write the failing observation: what would you see if this were broken?	Get the criterion from data — count the ambiguous case before debating it
Refinement spends 40 minutes arguing implementation	Negotiable	Ask who in the room may change the how without a change request	Return the decision rights, or accept it's a spec and size it as one
Everyone agrees it matters; nobody can name who's worse off without it	Valuable	Name the user and the behavior that changes the day it ships	Kill it, or attach it to the story that has a user
Rolls over repeatedly, reported as "80% done" every time	Small	Count days in progress against your sprint length	Split off the part already working and ship that this sprint
Estimate is "we can't estimate it"	(no letter)	This is a readout, not a diagnosis — rerun the chain from Valuable	See below

Two of the seven rows point at Small, and one points at Independent. That distribution matches what we've watched happen repeatedly: most stuck stories are stuck on size or coupling, and the other letters mostly serve to rule things out fast.

Estimable is a readout, not a criterion

The most common misdiagnosis is treating "we can't estimate this" as the problem to solve. It never is. Estimability is a display: it reports the state of the four letters above it. Fixing it directly is like adjusting a thermometer.

Watch a team treat it as a criterion. The story won't size, so they add detail — which makes the estimate worse, because now everyone can see the four stories hiding inside. Or they run a spike, answering a technical question that was never the blocker. SSO-14 got both treatments across four sprints and neither touched the disease.

What's worth reading off the display is not the number but the variance. A working heuristic — ours, not a research finding — is that when the highest estimate in the room exceeds roughly three times the lowest, the story is not being estimated at all. People are sizing different stories and the mean is a fiction. The gap between high and low is a map of the split you haven't made yet, drawn by the people who can already see it. The disagreement isn't friction on the way to a number; the disagreement is the finding.

Run this today: in your next estimation round, don't discard the outliers. Write the high and the low on the board and ask both people to describe their scope in one sentence. If the sentences describe different work, stop estimating and start splitting.

When breaking a letter is correct

INVEST is a diagnostic, not a compliance standard, and enforced as a standard it produces its own failure — the team that splits stories until each one is small, independent, testable, and delivers nothing anyone wants. Four legitimate violations:

Deliberately dependent stories in a sequence. A data migration or platform cutover is a chain by construction: you cannot link accounts before authentication exists. Forcing artificial independence produces stories that pretend to stand alone and then block each other silently. Keep the dependency and make it explicit — sequence the chain, name the release unit, accept that only the last story is user-visible. A named dependency is manageable; a denied one is not.

Spikes are not Estimable by design. A spike exists to resolve uncertainty, so demanding a confident estimate defeats it. What it must have instead is a time box and a decision it will produce: "Two days, and at the end we know whether we use the vendor's SDK or write our own client." That is Small (bounded by the clock) and Testable (a stated decision, not a stated learning) in a different currency. A spike with no decision attached is research, and it runs forever.

Compliance stories are not Negotiable. When behavior is set by statute, contract, or a published API you don't control, there is no conversation about the what. Fix the requirement, negotiate only the how.

Work whose value is indirect. Logging, observability, and platform stories fail a naive Valuable check because the beneficiary isn't a paying customer. Name the internal user and the decision the work makes possible, and the letter passes honestly.

What all four share: the letter is broken on purpose, with the reason written down. An undocumented violation is a defect; a documented one is a decision.

Run this on your board this week

The whole method fits in one refinement session:

1. Pick the specimens. The three oldest items in In Progress. Not the backlog — the backlog isn't failing yet.

2. Run the chain in order. Valuable → Testable → Independent → Small. Stop at the first real break. Ignore Estimable on this pass.

3. If the break is Testable, go count something. Find the claim that is a countable fact about your data and get the number before you debate the policy again. Then write the acceptance criterion the number implies — where that line sits against your team's blanket standards is worth being deliberate about (Definition of Done vs Acceptance Criteria).

4. If the break is Small, mine the estimate spread. High and low, one sentence of scope each, split along the difference.

5. If nothing breaks, the story isn't stuck for a story reason. It's stuck on a person, an environment, a dependency outside the team, or a priority nobody will say out loud. INVEST won't find that, and pretending it will is how teams rewrite a perfectly good story four times.

Step five carries as much weight as the rest. A diagnostic that never returns "not this" isn't a diagnostic.

SSO-14 shipped in the end, and what unstuck it wasn't better story-writing. It was a facilitator who stopped asking "is this a good story?" and started asking "which of the six is broken, and how would I know?" — then someone who ran a query instead of holding a fourth meeting. Forty-seven rows. That's what four sprints of an unestimable story turned out to be made of.

Sources

• Bill Wake, INVEST in Good Stories, and SMART Tasks, XP123, 2003 — the original definition of the six criteria and the vertical-slicing "layer cake" metaphor.

• Bill Wake, Negotiable Stories in the INVEST Model, XP123 — the author's later elaboration on what Negotiable actually asks of a team.

• Agile Alliance, INVEST glossary entry — the community-standard summary of the acronym.

• Mike Cohn, User Stories Applied: For Agile Software Development (Addison-Wesley, 2004) — the book that popularized INVEST and the story-splitting practices built on it.