User:Dpolist/INVEST (mnemonic)

Scrum INVEST mnemonic
The INVEST mnemonic is frequently used as a reminder of the characteristics of a good quality user story in a Scrum backlog or [|XP] project. This article describes INVEST from a Scrum point of view, although the same idea can be used in XP projects.

Independent
One of the characteristics of Agile Methodologies such as Scrum (like 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 a Scrum project is a Sprint 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 Scrum 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 beats one of the Agile Principles, which is to continuously deliver valuable software.

Estimatable
If a user story size cannot be estimated, it will never be planned, tasked, and, thus, become part of a Sprint. So there's actually no point in keeping this kind of user story in the Product Backlog at all. Most of the times, estimation cannot be executed due to the lack of supporting information either in the story description itself or directly from the Product Owner.

Sized appropriately or Small
Try to keep your user story sizes between 0-13 story points. 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 a Sprint Backlog becomes closer.

Testable
You should always bear in mind that a story should be considered DONE, among other things, if it was tested successfully. If one cannot test a story due to lack of information (see "Estimatable" above), the story should not be considered a good candidate to be part of a Sprint Backlog. This is especially true for teams employing TDD - Test Driven Development