INVEST (mnemonic)
The INVEST mnemonic was created by Bill Wake[1] as a reminder of the characteristics of a good quality user story, as may be used in a Scrum or Kanban backlog or XP project.
| Letter | Meaning | Description |
|---|---|---|
| I | Independent | The user story should be self-contained, in a way that there is no inherent dependency on another user story. |
| N | Negotiable | User stories, up until they are part of an iteration, can always be changed and rewritten. |
| V | Valuable | A user story must deliver value to the end user. |
| E | Estimable | You must always be able to estimate the size of a user story. |
| S | Small | User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. |
| T | Testable | The user story or its related description must provide the necessary information to make test development possible. |
Independent
One of the characteristics of Agile Methodologies such as Scrum, Kanban or XP is the ability to move stories around, taking into account their relative priority - for example - without much effort. If you find user stories that are tightly dependent, a good idea might be to combine them into a single user story.
Negotiable
The only thing that is fixed and set in stone in an agile project is an iteration backlog (and, even then, it can be broken). While the story lies in the product backlog, it can be rewritten or even discarded, depending on business, market, technical or any other type of requirement by team members.
Valuable
The focus here is to bring actual project-related value to the end-user. Coming up with technical stories that are really fun to code but bring no value to the end-user violates one of the Agile Principles, which is to continuously deliver valuable software.[2]
Estimable
If a user story size cannot be estimated, it will never be planned, tasked, and, thus, become part of an iteration. So there's actually no point in keeping this kind of user story in the Product Backlog at all. Most of the time, estimation cannot be executed due to the lack of supporting information either in the story description itself or directly from the Product Owner.
Small
Try to keep your user story sizes to typically a few person-days and at most a few person-weeks. Anything beyond that range should be considered too large to be estimated with a good level of certainty or even "epic" and broken down into smaller user stories. There's no problem in starting with epic stories, as long as they are broken down when the time to place them in an iteration backlog becomes closer.
Testable
Bear in mind that a story should only be considered DONE, among other things, if it was tested successfully. If one cannot test a story due to lack of information (see "Estimate-able" above), the story should not be considered a good candidate to be part of an iteration Backlog. This is especially true for teams employing TDD - Test Driven Development
External links
- Jeff Sutherland's Blog
References
- ↑ Bill Wake's original article: INVEST in Good Stories, and SMART Tasks
- ↑ Principles behind the Agile Manifesto