INVEST
A checklist for whether a user story is ready to build: Independent, Negotiable, Valuable, Estimable, Small, Testable (Bill Wake, 2003). The questions I actually ask for each letter, and how to split a story that fails 'Small'.
On this page
INVEST is a quick test for whether a user story is ready to build. It comes from Bill Wake (2003), and it’s the backbone of my definition of ready (see From Statement of Work to Done: Requirements Both Ends Can Build From).
The letters, and the questions I ask
Independent. Can this be finished on its own, without waiting for another story? If two stories always have to ship together, they’re probably one story, or they need a contract between them so both can proceed in parallel.
Negotiable. A story is the start of a conversation, not a fixed spec. During development it may turn out that the original ask isn’t possible, or that there’s a better way. The story should be flexible about the how while holding the goal steady.
Valuable. Why are we doing this? A valuable story is a vertical slice: the UI that shows the information, the service that transforms it, the data underneath. A thin slice through every layer stays focused and is easier to review than a horizontal “all the backend first” chunk.
Estimable. Does the team know enough to estimate it?
- Have the dependencies been identified?
- Are the resources it needs understood? (Is the endpoint it calls documented? Does the data exist?)
- For a new visual feature: is there a mock-up, are the logical steps defined, and has the UI team seen it?
- If not, the first piece of work is a time-boxed spike to find out, not the feature itself.
Small. Can it be completed within one sprint? It’s hard to stay focused on a single task for much longer, and big stories hide unknowns. A large story must be split.
Testable. What are the acceptance criteria? Can the outcome be measured and demonstrated? Is the potential impact of the change understood, and what improvement should we expect to see?
When a story fails “Small”: splitting patterns
- Workflow steps: the happy path first; edge cases as follow-ups.
- Business rule variations: one rule per story.
- Data variations: one input type or one source first.
- Interface: a basic UI first, polish later; or one platform first.
- CRUD: view before edit before delete.
- Spike: time-boxed research when the story isn’t estimable yet.
Each split should still be a vertical slice that delivers something a user could see, otherwise you’ve just split the work into layers, not into stories.
In the age of AI
The same checklist turns out to describe what an AI coding agent needs to do good work: a clear why, concrete examples of correct behaviour, known dependencies and a small enough scope to verify. A story that passes INVEST is also a story an agent can help with; a story that fails it just gets built wrong faster.
- #user-stories
- #agile
- #definition-of-ready
- #requirements
- #story-splitting
- #ways-of-working
↩ Linked from (2)
…own until it's independent, small and testable is one an agent can do well and a reviewer can actually check (INVEST). A ready ticket is an AI-ready ticket (From Statement of Work to Done: Requirements Both Ends Can Buil…
…they're another team's. Small: it fits comfortably in a sprint; if not, it's split into thin vertical slices (INVEST is a good test). Unknowns: if the team can't estimate it, the first ticket is a time-boxed spike, not t…
↪ Links to (1)
Related by topic
- Growingcase study
A Testing Strategy Teams Actually Adopted
Frontend craft - Seedcase study
The Two-Minute Timeout
Testing, quality - Seedcase study
Cutting CI Feedback Time with Checkpoint Restarts
Developer tooling - Seed
AI-Era Supply Chain: What to Trust When Anything Can Be Generated
Testing, quality