The INVEST mnemonic was created by Bill Wake as a reminder of the characteristics of a good quality user story

User story

In computer programming a user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. User stories are used with Agile software development methodologies for the basis of what features that can be implemented...

, as may be used in a Scrum

Scrum (development)

Scrum is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering....

 backlog or XP

Extreme Programming

Extreme programming is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements...

 project.

This article describes INVEST from a Scrum point of view, although the same idea can be used in XP projects.

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 a Sprint, 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	Sized appropriately or 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 or XP

Extreme Programming

Extreme programming is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements...

 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.

Estimable

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 "Estimable" 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

Test-driven development

Test-driven development is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new...