The INVEST Test for Good User Stories: A Field Checklist
INVEST is a mnemonic for six quality criteria that a well-formed user story should satisfy: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Developed by Bill Wake, it is widely used as a pre-Sprint refinement checklist. Here is how to apply each criterion in practice.
The Six Criteria
Independent: Can this story be developed without depending on another story that is not yet done? Stories with hard dependencies on other stories create sequencing problems in Sprint Planning and make it difficult to reorder the backlog. Signs of failure: the story explicitly requires data, a UI component, or a service that will only exist once another story is complete. Fix: split the dependency into a shared foundation story that can be built first, or merge the stories if they are inseparable.
Negotiable: Is this story a contract or a conversation? A story is not a specification. It is a placeholder for a conversation between the Product Owner and the Development Team about what needs to be built. If a story is so detailed that there is nothing left to discuss, it is probably a requirement document masquerading as a story. Signs of failure: the story has more than a few lines of text and leaves no room for the team to ask how. Fix: move detail into acceptance criteria and keep the story itself to user-need level.
Valuable: Does this story deliver value to the user? A story should describe a user outcome, not an implementation step. Signs of failure: the story describes a technical task ('create a database index', 'refactor the authentication module') with no connection to a user benefit. Fix: tie the story to a user outcome. If the story cannot be framed in terms of what a user can do as a result of it, it belongs in a technical task list, not the Product Backlog.
Estimable: Can the Development Team estimate the effort to complete this story? If the team cannot estimate a story, it is usually because they lack information (domain knowledge, technical clarity, or both). Signs of failure: the team consistently passes on a story in estimation sessions or gives it an unusably wide range. Fix: the Product Owner and Development Team discuss the story until the team has enough clarity to estimate.
Small: Can this story be completed within a single Sprint? A story that cannot be completed within a Sprint is an epic -- a collection of related stories that needs to be split. Signs of failure: the team estimates the story at more than one-third of the Sprint velocity. Fix: split the story along user value dimensions (first the basic capability, then the enhanced version) rather than implementation layers.
Testable: Can the team verify that the story is complete? If there is no way to test whether the story is done, there is no way to know when it is done. Signs of failure: the story describes a non-functional quality ("the system should be fast") without a measurable specification. Fix: add acceptance criteria that convert the quality into a measurable statement.
XNM supports public-sector and capital-project organisations in building effective Scrum practices, including Product Backlog Refinement. Reach out to XNM's program & project delivery advisory team for support with your agile delivery.