INVEST is an acronym first suggested by Bill Wake, the author of Extreme Programming Explored and Refactoring Workbook.   They are the six attributes of user stories to focus on to ensure that they are well written.

Independent - User stories should be independent of one another.  They should be discrete with no overlap in the description of the problem or the solution.

Negotiable - Up until the point when development for a solution to a user story commences, the user story is negotiable.  It can be changed to add greater detail, it can be split into two or more stories to make the stories more granular, checks can be added, changed or removed.

Valuable - User stories must represent value to users.  The "so that" part of a user story provides the reason why the problem is important to the user, so provide a good indicator of the value of the story.  If the story represents little or no value to the user, then there is little point in developing a solution for it.

Estimatable - The development of the stories should involve all of the team in understanding the problem and the solution they intend to build.  That understanding needs to be deep enough that the team are able to confidently estimate the size of the user story.

Small - User stories should represent a small amount of effort to develop their solution.  Stories should be small enough so that it's easy to track their progress over a few days and understand whether the work is on track or falling behind.  Teams that use scrum should ensure that user stories are of a size where the effort required is no greater than the effort available during a sprint.   Ideally a number of user stories should be able to be completed during a sprint, but not so many that the team spends more time managing their work than actually developing the solution.  ( e.g. Around ten to twenty stories for an average size delivery team (6-8 people), working to two week sprints.)

Testable - User stories should be written so that it is easy to identify and describe the tests that check whether or not the problem the user story describes has been solved.

The use of INVEST is a really good way to check whether user stories are well-written.  We've found that it is best applied to that set of stories that are deemed to be ready for development, and can actually form part of the criteria of the Definition of Ready.

 Trying to apply INVEST to all stories before they are ready for development, will result in attempts to define all the user stories to a granular level upfront.  In so doing, the result is effectively the same as producing a requirements catalogue and the teams way of working starts to shift away from being agile and moves towards a more waterfall approach.