INVEST Criteria: 6 Qualities of a Good User Story

By Tara Minh · Updated Oct 10, 2026

INVEST is a checklist for judging a user story before a team commits to it. Each letter names one quality: Independent, Negotiable, Valuable, Estimable, Small, Testable. A story that passes all six is easy to plan, build, and verify. A story that fails one usually tells you exactly what to fix.

Key Facts

• Bill Wake introduced INVEST in his article "INVEST in Good Stories, and SMART Tasks", dated August 17, 2003.
• The six qualities are Independent, Negotiable, Valuable, Estimable, Small, and Testable.
• Wake's companion acronym, SMART, applies to tasks, not stories: Specific, Measurable, Achievable, Relevant, Time-boxed.
• Wake describes a good story as typically "at most a few person-weeks" of work, and some teams hold it to a few person-days.
• Richard Lawrence's guide to splitting user stories names nine splitting patterns and starts by checking a story against INVEST.

Where INVEST came from

Bill Wake published the acronym in 2003 in the article "INVEST in Good Stories, and SMART Tasks" on his xp123.com site. He was writing for Extreme Programming teams, who were already using index cards for requirements. What they lacked was a quick way to tell a good card from a weak one.

INVEST filled that gap. It isn't a process or a framework. It's a mnemonic: six questions you can ask in under a minute during backlog refinement. The idea has outlived the XP community that produced it, and most Scrum and Kanban teams that write user stories borrow it in some form.

The six qualities, one at a time

Independent

Wake's wording: stories shouldn't overlap in concept, so they can be scheduled and implemented in any order. The reason is practical. If story B can't start until story A finishes, your sprint plan is hostage to A. Wake concedes that perfect independence isn't always reachable. His example is an estimate that shifts with order: three points for the first report, then one point for each of the others.

Quick test: can the product owner reorder this story in the backlog without anyone saying "but that needs...?"

Negotiable

A story isn't a contract. Per Wake, it captures the essence of a need, and the details get worked out between the customer and the developers. That's why a story is short. If it already specifies every field, color, and edge case, there's nothing left to talk about, and you've written a spec.

Quick test: could two reasonable developers build it differently and both satisfy the story?

Valuable

Every story should matter to a customer or user. Wake notes that splitting should slice vertically through the layers, so each piece delivers something a person can use, rather than a "database layer" story nobody can see. Lawrence's guide makes the same point, defining a vertical slice as a work item that delivers a valuable change in system behavior, and calls out Valuable as the most common INVEST failure when you check a story before splitting it.

Quick test: if only this story shipped this sprint, would someone outside the team notice?

Estimable

The team must be able to size the story well enough for the customer to rank and schedule it. Wake says estimability depends on how well the story is negotiated, how big it is, and the team's experience. When a story fails here, he suggests a time-boxed spike to learn enough to estimate the rest. If you size in story points, an unestimable story is one where the team's numbers spread wildly in planning poker.

Quick test: can the team commit to a rough size without asking for a week of research first?

Small

Wake puts a good story at typically no more than a few person-weeks of work, and notes some teams keep it to a few person-days. He adds that "it would take me more than a month" often means the speaker doesn't yet understand the scope. Smaller stories also tend to get more accurate estimates.

Quick test: can it be finished and demonstrated inside one sprint, with room left over?

Testable

Wake argues that writing a story implies you understand it well enough to write a test for it. If the customer can't say how they'd check it, the story may be unclear, may not reflect real value, or may need help defining success. He also says several teams reported higher productivity when they required customer tests before implementation, and that non-functional needs like performance and usability should be made testable too. This is where acceptance criteria come in.

Quick test: can you write down, in advance, what "done" looks like for this story?

INVEST vs SMART vs the 3 Cs vs Definition of Ready

Teams often mix these up, partly because they sit near each other in the workflow. They answer different questions.

SMART is INVEST's sibling for the next level down. In the same article, Wake expands it as Specific, Measurable, Achievable, Relevant, and Time-boxed, and he notes that many variations exist. His key test for a task is whether you can mark it as done. Stories get INVEST; the tasks you break them into get SMART.

The 3 Cs describe what a story contains. Wake's article credits Ron Jeffries with the three components: the Card (a brief written statement), the Conversation (where the details emerge), and the Confirmation (tests that verify the story). INVEST then judges the result. Notice how they line up: Negotiable is the Conversation, and Testable is the Confirmation.

Definition of Ready is a team's own entry gate for the sprint, and it often uses INVEST as its backbone. The difference is ownership. INVEST is a general-purpose lens; a Definition of Ready is a local rule, such as "has acceptance criteria and a design link." Use INVEST to judge a story, and the Definition of Ready to agree when it can start.

How to apply INVEST step by step

1. Pick the next refinement candidates. Take the top of the product backlog, not random items.
2. Read the story aloud, then score each letter. Pass, weak, or fail is enough. Don't debate decimals.
3. Fix the cheapest failures first. An untestable story often just needs a sentence of acceptance criteria. A story that's too large needs splitting.
4. Split rather than shrink wording. Cutting words doesn't shrink work. Cut scope along a workflow step, a rule, or a data variation.
5. Re-score after the fix. Splitting can break Independent or Valuable, so check the pieces too.
6. Record the result where the team looks. A column on the board or a tag on the ticket works.

INVEST scoring checklist (copy this)

Score each story 0 (fails), 1 (weak), or 2 (passes). Anything below 9 out of 12 goes back for work, and any single 0 blocks it from the sprint. The cutoff is a suggestion; adjust it to your team.

Add a "Fix needed" note every time you score below 2. That column becomes your refinement agenda.

Before and after: rewriting stories by function

INVEST isn't only for software. Any team that writes requests as short user-centered statements can use it. Here are rewrites across departments.

Look at what changed. The weak versions are vague wishes or technical chores. The rewrites name a real person, a visible outcome, and something you could check. The operations example is the classic Valuable failure: a database table is a layer, not a benefit.

Splitting stories without breaking INVEST

When a story fails Small, resist the urge to carve it by technical layer. Richard Lawrence of Humanizing Work lists nine splitting patterns:

1. Workflow steps
2. Operations (such as create, read, update, delete)
3. Business rule variations
4. Variations in data
5. Data entry methods
6. Major effort
7. Simple/complex
8. Defer performance
9. Break out a spike

His first step is a check that the story meets INVEST except for Small. If it isn't a valuable increment, combine it with the pieces it needs so the whole delivers value; only then ask whether it's too big.

Two of the patterns are easy to try tomorrow. On workflow steps, Lawrence notes the biggest value often comes from the beginning and end of a workflow, so build the simple end-to-end path first and add middle steps later. On business rule variations, one story can hide several stories that reach the same goal under different rules. His flight example splits flexible-date search into separate rules, like "n days between x and y" or "a weekend in December."

For a non-software case, take "As an HR lead, I can run a full performance review cycle." Splitting by workflow steps gives you a thin first slice: "I can send a self-review form to one team and see who has submitted." Each later story adds a step, and each still delivers something usable.

Do's and don'ts

Do

• Treat INVEST as a conversation starter, not a score to defend.
• Fix Valuable and Testable first; they expose most vague stories.
• Pair INVEST with epics, features, and stories so you know which level you're scoring.
• Rewrite the story when the team learns something new in the Conversation.

Don't

• Don't apply INVEST to epics. They're meant to be large, and they'll fail Small by design.
• Don't use INVEST scores to compare teams or rank people.
• Don't chase perfect Independence. Wake himself shows dependencies can remain.
• Don't skip the Conversation because a story scores well on paper.

Common mistakes

Treating Small as the whole job. A story can be small and still worthless. A two-day "refactor the config file" passes Small and fails Valuable. Check all six.

Writing acceptance criteria that restate the title. If the criteria say "the feature works," the story isn't Testable. Spell out the observable result.

Splitting by team or layer. "Front-end story" and "back-end story" depend on each other, so you've broken Independent and Valuable in one move.

Scoring alone. One person scoring in private misses the point. The Estimable and Negotiable checks need the people who will do the work.

INVEST won't write good stories for you, but it makes weak ones obvious fast. Run it on the top ten items in your backlog this week, fix the zeros, and keep the checklist in your next sprint planning session.