INVEST criteria for Agile user stories
By Nick Butler
The INVEST criteria spell out how to create Agile user stories that deliver valuable working software early and often. They show you how to specify your requirements in ways that follow the principles and values of Agile.
The INVEST mnemonic is designed to make it easy to remember what effective Agile user stories look like. With that in mind, we’ve put together a short, simple description of each of the criteria and an explanation of why it matters.
You’ll also get examples of user stories that do and don’t meet the INVEST criteria, find out how the criteria fit with the definition of ready and learn about the origins of the criteria.
Note: If you’re working on a non-software project, just replace the phrase “working software” with “working solutions”.
Under the INVEST criteria, good user stories are:
Here’s what that means and why it matters.
The story is not dependent on other stories getting done.
Why it matters: Dependencies cause delays. You don’t get user-ready working software until both or all dependent stories are complete.
The story prompts but doesn’t prescribe a solution.
Why it matters: Treating the story as an evolving conversation between product owner and development team builds a shared understanding and harnesses everyone’s expertise: the product owner knows the benefits you’ll bring the users and the development team knows the best way to do this. And accepting that the story may change lets you adjust what you deliver as you learn more.
The story makes clear the benefit it delivers the users.
Why it matters: In Agile, your goal is to deliver valuable working software. So your user stories need to explicitly state the value they’ll bring. What user needs does it meet, what risks does it mitigate, what costs does it save, what learnings does it allow? How does the story help you achieve your vision for the product?
The story gives the development team enough detail to estimate the size of the story.
Why it matters: You need to know the size of the stories so you can plan an iteration that will deliver working software. Plus, product owners need to know the size so they can prioritise the stories that give the most value for the least effort.
The story is the smallest piece of work that will deliver useful software.
Why it matters: Agile works in short iterations so you can get fast feedback from your users. If you want to deliver working software each iteration, short iterations necessarily require small stories. The smaller the story, the more likely it will be delivering value by iteration’s end.
The story is clear enough that you can assess if the story is done.
Why it matters: If there isn’t a Yes or No answer to the question, “Have each of the acceptance criteria been met?” then developers can’t write automated tests and the product owner can’t check the story when it’s up for acceptance.
Examples of user stories assessed against the INVEST criteria
It can help you check your own user stories against the INVEST criteria if you get to see examples of stories that meet them and stories that don’t.
With that in mind we’ve put together a set of examples.
Get user story examples assessed against the INVEST criteria
INVEST criteria and the definition of ready
Some people like to have a definition of ready. This defines what a story needs to look like before you can accept it into the work for the next iteration.
The INVEST criteria often work well as a definition of ready. You might need to expand on them if your development team tends to find they can’t pick up stories the moment the iteration starts. They might be missing content, images or other assets, contacts for external expertise, that kind of thing. Watch out for the definition of ready becoming a blocker though.
The origin of the INVEST criteria
XP expert Bill Wake first formulated the INVEST criteria for Agile user stories in a blog post called INVEST in Good Stories, and SMART Tasks.
Since then there have been lots of different formulations for the individual INVEST criteria. We’ve described them in various ways ourselves, as has Bill Wake (in fact the “S” now stands for Scalable in his latest version).
In this post, we’ve limited the description of each of the criteria to a single sentence to help keep them memorable.
User stories: a beginner’s guide
Definition of ready and definition of done: What’s the difference?