ANSWER

INVEST is an acronym that can help a Product Manager or Developer create quality user stories.  INVEST stands for Independent, Negotiable, Valuable, Estimable, Sized-Appropriately, Testable.  

I - Independent:  The user story should be self-contained if at all possible to avoid dependencies on other user stories.  Since one characteristic of agile methodologies is the ability to be flexible and re-prioritize what’s important, independent user stories allow for flexibility during iteration planning. If you do find that your user stories are dependent upon one another, you may be able to combine smaller user stories together that have a dependency between one another.  Similarly, you can divide larger dependent user stories into smaller stories such that one of the new smaller stories contains and isolates the overlapping portion of the larger stories.

N - Negotiable:  User stories can always be changed or rewritten up until the point of coding.  This further supports the flexibility associated with agile methodologies.   Since requirements often evolve or rise and fall in priority, user stories should be able to adapt with the changing requirements.

V - Valuable:  A user story represents a goal of an end user or purchaser and should deliver functionality that is deemed valuable.  This means that specifics of the technical design are not something that you would document as user stories.  However, some technical requirements have a component which is valuable to a user.  A user might expect pages to load within 2 seconds.  The user story would specify the need for 2 second page load times while the specifics of the physical implementation of this would be left out.

E - Estimable:  You should always be able to estimate the size of a user story.  Sometimes, developers won’t have the experience required to size a particular situation or needed for a user story.  When this occurs the user story can be split into two separate user stories.  The first is a “spike” which is where developers do some quick research to determine the feasibility of something or get a better idea of how long it might take to implement the particular feature.  The spike is always time-boxed, meaning it is limited to a pre-defined amount of time.  The “spike” user story might be named “Research (something) to determine…)”, while the second user story is where the functionality will actually be delivered.  These two user stories should be scheduled into two separate iterations such than the spike can be completed and the feasibility of the second user story assessed before coding begins.  This gives the team time to react if problems arise from the spike.

S - Sized Appropriately:  User stories shouldn’t be too big or too small.  So how do you decide what size is right.  First, any user story that can’t be completed by a developer within a single iteration (or by a developer pair when paired programming is being used) is too big.  The user story should be subdivided into two or more smaller stories.  Similarly, there is no need to make user stories too granular just for the sake of decomposing features.  If features group well together and complement each other then it makes sense to make a single user story.  For instance, “As a job seeker I want to be able to add, delete, and edit a job skill on my electronic resume so that I can maintain an accurate listing of my skills.”  There is no reason to split “add, delete, and edit” into multiple user stories unless one of them creates a significant amount of work that would make the user story too large for the iteration.

T - Testable:  User stories must be testable in order to ensure that development is complete and has been done correctly.  So when are user stories not-testable?  Often, if the analyst isn’t carful, non-functionality requirements are written in a manner which is un-testable.  Consider the example, “pages should always load quickly”.  There are two un-testable components of this statement; “always” and “quickly”.  A testable statement would be “pages should load within 1.5 seconds 97% of the time”.

--
Chris Adams
LinkedIn Profile