INVEST Criteria for Better User Stories

Contributor
Apr 8
5 min read

INVEST is a six-letter acronym for the qualities of a good user story: Independent, Negotiable, Valuable, Estimable, Small, Testable. Coined by Bill Wake in 2003, it's the most widely-used checklist for story readiness. Used as a real check (not lip service), it catches the common failure modes that produce backlog drama.

Independent

The story shouldn't depend on another story being completed first.

Why: dependencies pile up. Story B can't start until A is done. Story C can't start until B. Now reordering breaks everything.

Test: can the team reasonably pick this story up without first finishing another specific story?

When dependencies are unavoidable:

Make them explicit
Order stories so the prerequisite comes first
Consider whether the dependent stories should be combined or split differently

A backlog with many tightly-coupled stories produces planning paralysis.

Negotiable

The story describes intent, not exact specification. Implementation details emerge through conversation.

Bad: "As a user, I want a dropdown menu in the upper-right corner showing my recent items with a max of 10 entries..."

Better: "As a user, I want quick access to items I recently viewed."

The first locks in UI. The second describes the need; the team designs the implementation.

The story is a placeholder for a conversation. If everything is specified, there's nothing to negotiate, and the team can't propose better solutions.

Valuable

Each story delivers value to a user or stakeholder.

Test: "What value does this story deliver?"

If the answer is internal-only ("makes the code cleaner"), that might not be a user story — it might be tech debt work. Both are valid; both need different treatment.

The value isn't always to an end user. Internal users count: "as a support agent, I want to look up recent orders." But there should be value to someone identifiable.

Estimable

The team can roughly estimate the effort.

Test: when the team looks at the story, do they have a rough sense of effort?

If the answer is "no idea — we'd need to investigate," that's information. Either:

The story is too vague (clarify)
The story is too large (decompose)
The team needs a spike (time-boxed investigation) before estimating

Stories that aren't estimable can't be planned around. The team might commit to them and discover they're much bigger than expected.

Small

The story fits comfortably in a sprint, ideally smaller.

Test: rough estimate under a couple of days of work for the team. Under a week if the team is small.

Large stories:

Sit "in progress" for the whole sprint
Block other work
Hide their complexity until late
Make incremental shipping impossible

Splitting techniques:

By user role
By workflow step
By data type
By happy path vs. edge cases
By platform (web first, mobile next)

The right splits produce stories that each deliver value, not stories that are "Step 1: implement button. Step 2: make button work."

Testable

There's a clear, observable way to determine completion.

Test: can someone (not the developer) verify the story is done?

If the answer requires the developer to demonstrate it, the story isn't testable. Specific acceptance criteria make it testable.

Untestable stories drift. Three engineers have three opinions about whether it's done; arguments ensue.

Using INVEST as a Checklist

During backlog refinement, check each story against INVEST:

Story: As a user, I want to view my recent orders.

I: Independent? Yes, no other story is a prerequisite.
N: Negotiable? Yes, UI not specified.
V: Valuable? Yes, customers asked for this.
E: Estimable? Roughly 2-3 days based on current architecture.
S: Small? Yes, fits in a sprint.
T: Testable? Yes, acceptance criteria define done.

→ Ready for the sprint.

When a story fails one or more checks, fix it before sprint planning.

When INVEST Is Hard to Apply

A few specific cases.

Foundational stories. The first story for a new module may seem to violate Independent (nothing depends on it yet) but is actually a special case — it's the foundation.

Spike stories. Time-boxed investigation. Not really a user story; should be tracked separately.

Refactoring stories. Pure technical work. May fit "tech debt" rather than "user story" format.

Compliance stories. Required by regulation, not derived from user need. The "value" is regulatory; the user isn't a person.

Don't force INVEST onto stories that aren't really user stories. Use the right format.

INVEST vs. SMART

INVEST is sometimes compared to SMART (Specific, Measurable, Achievable, Relevant, Time-bound). They overlap but address different things.

SMART describes goals
INVEST describes user stories

For a project goal, use SMART. For backlog items, use INVEST.

Anti-Patterns

Lip service. Team reads the acronym; doesn't check stories against it. Stories continue to fail in the same ways.

Forced fit. Squeezing every backlog item into the story format. Some work isn't user stories.

Negotiable as excuse. Treating "negotiable" as "we'll figure it out later." Negotiable means open to discussion; not undefined.

Small as small. Splitting until stories are too small to deliver value. "Add the button" alone isn't a story; "user can save changes via the button" is.

A Walked Example

Initial story:

As a user, I want a comprehensive dashboard.

INVEST check:

Independent: probably yes
Negotiable: too vague to know — "comprehensive" is undefined
Valuable: nominally, but to whom doing what?
Estimable: no, "comprehensive" could mean anything
Small: probably not
Testable: not without more specifics

Refined:

As a project manager, I want to see the current status of all my active projects on one screen, so that I can quickly identify any at risk.

Better. Now:

Independent: yes
Negotiable: implementation open
Valuable: PM identified
Estimable: roughly 3-5 days
Small: yes
Testable: with acceptance criteria specifying which info appears

Acceptance criteria fill in the details:

- Dashboard shows all projects PM owns
- Each project shows: name, status (green/yellow/red), next milestone, owner
- Projects sorted by risk: red first, then yellow, then green
- Mobile-responsive

The story is now ready for the sprint.

Refining Stories in Practice

Backlog refinement (or grooming) is the regular practice of getting stories ready for sprint planning.

A working cadence:

Mid-sprint, look at the top 10-15 stories
Apply INVEST to each
Refine where needed
Estimate
Stories that can't be made INVEST-compliant in refinement aren't ready for the sprint

This prevents the sprint-planning meeting from being a story-refinement meeting.

Key Takeaway

INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, Testable. Use it as a real checklist during backlog refinement, not as a slogan. Stories failing one or more criteria need work before sprint planning. The most common failures: stories too large (Small), too vague (Estimable), or without clear completion (Testable). The discipline of INVEST checking prevents sprint planning from becoming story-refinement and reduces drift during the sprint.

ShiftQuality