INVEST Criteria for User Stories Explained
INVEST is a checklist for writing good user stories, standing for Independent, Negotiable, Valuable, Estimable, Small, and Testable. A story that satisfies all six qualities is generally ready to be worked on; a story that fails one or more usually needs to be rewritten, split, or clarified before a team commits to it.
Quick facts
- INVEST was coined by Bill Wake as a simple, memorable checklist for user story quality.
- A story can be technically well-written but still fail INVEST if it's too large, too dependent on other work, or too vague to estimate.
- This builds on How to Write User Stories Effectively, covering the general writing process.
The INVEST criteria, one by one
| Letter | Meaning | What it looks like when violated |
|---|---|---|
| I — Independent | The story can be worked on without being blocked by another unfinished story | Story can't start until a different, unrelated story finishes first |
| N — Negotiable | The story describes a need, not a fixed, over-specified solution | Story dictates exact implementation details, leaving no room for the team's judgment |
| V — Valuable | The story delivers real value to a user or the business | Story is purely technical with no clear connection to user or business value |
| E — Estimable | The team has enough information to estimate the effort involved | Story is too vague or too large for the team to confidently size it |
| S — Small | The story can be completed within a single sprint | Story is really several stories bundled together |
| T — Testable | It's possible to verify objectively whether the story is done | Story has no clear acceptance criteria or success condition |
Why INVEST matters
A story that violates INVEST tends to cause real problems later, even if it looked fine when written. A story that isn't independent creates scheduling bottlenecks. A story that's too large gets partially finished and carried across multiple sprints, making progress hard to track. A story that isn't testable leads to disagreements about whether it's actually done. Running every story through the INVEST checklist before committing to it catches these problems while they're still cheap to fix — before work has started, not after.
A worked example
Story that fails INVEST: "As a user, I want the entire checkout flow rebuilt with a new design, new payment options, and improved performance."
This fails Small (it's really several stories bundled together), likely fails Estimable (too broad to size confidently), and may fail Testable (no clear, specific success condition).
Rewritten to pass INVEST: Split into separate stories: "As a customer, I want to pay using digital wallets, so that I can check out without entering card details" (with specific acceptance criteria), "As a customer, I want checkout to load in under 2 seconds, so that I don't abandon my purchase due to slowness" (with a specific, testable performance target), and so on. Each smaller story is now independent, estimable, small, and testable individually.
Common mistakes when applying INVEST
- Only checking a story against INVEST after it's already in the sprint, rather than during backlog refinement when it's still easy to fix.
- Treating INVEST as a one-time check rather than something to revisit as understanding of a story improves closer to when it's actually worked on.
- Focusing only on "Small" and ignoring the other five criteria, missing issues like unclear value or untestable acceptance criteria.
- Applying INVEST too rigidly to spikes or research stories, which sometimes can't be estimated the same way as typical delivery work — INVEST is a guideline, not an absolute rule for every backlog item.
FAQ
Does every user story need to pass all six INVEST criteria? Ideally yes, for stories that are about to be worked on — a story failing one or more criteria is usually a signal it needs refinement before the team commits to it, not a fatal flaw that makes it unusable forever.
Who is responsible for checking stories against INVEST? Typically the product manager or business analyst writing the story, though backlog refinement sessions with the whole team are a common place to catch INVEST violations collaboratively.
What's the most commonly violated INVEST criterion? "Small" and "Independent" are frequently violated in practice, since large, interdependent features often get written as a single story before being properly broken down.
Is INVEST specific to Scrum, or does it apply to other agile methods too? INVEST originated in the agile community broadly and applies to any iterative, story-based approach to managing work, not just Scrum specifically.