The INVEST mnemonic for agile software projects was created by Bill Wake as a reminder of the characteristics of a good quality Product Backlog Item (commonly written in user story format, but not required to be) or PBI for short. Such a PBI may be used in a Scrum or Kanban backlog or XP project.
Contents
Independent
One of the characteristics of Agile Methodologies such as Scrum, Kanban or XP is the ability to move PBIs around, taking into account their relative priority - for example - without much effort. If you find PBIs that are tightly dependent, a good idea might be to combine them into a single PBI.
Negotiable
The only thing that is fixed and set in stone in an agile project is an iteration backlog (and, even then, this "can be clarified and re-negotiated... as more is learned."). While the PBI 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 stakeholder. Coming up with technical PBIs that are really fun to code but bring no value to the stakeholders violates one of the Agile Principles, which is to continuously deliver valuable software.
Estimatable
If a PBI 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 PBI 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 PBI sizes to typically a few person-days and at most a few person-weeks (a good rule of thumb is that any single Product Backlog Item does not take more than 50% of an iteration; for example a single item won't take more than 5 days for a 2 week / 10 day sprint). Anything beyond that range should be considered too large to be estimated with a good level of certainty - Scrum calls these large PBIs "Epics" where an Epic will take more than one iteration to deliver and, necessarily, will need to be broken down into smaller PBIs that can fit comfortably within Iterations. There's no problem in starting with epic PBIs, as long as they are broken down when the time to place them in an iteration backlog comes closer. This implements Lean's Just In Time analysis concept.
Testable
Bear in mind that a PBI should only be considered DONE, among other things, if it was tested successfully. If one cannot test a PBI due to lack of information (see "Estimable" above), the PBI 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.