User stories are a common method of communicating requirements in Agile software development projects.
A user story is a description of features, functions and uses of a product. In most cases, user stories follow the format of Actor — Action — Result in the form of “as a ____ I need to ____ so that I can ___”.
A simplistic example of user story is: “As a user (actor) I need to log into (action)to the application so that I can view my records (result)”
The information in a user story is pertinent to more than one project stakeholder including; testers, developers, designers and business stakeholders. It is therefore important to format user stories in a manner they can effectively communicate what is required.
One concept used in formatting effective user stories is the concept of INVEST.
The initials in INVEST stand for the following:
Independent — Every user story should be standalone and have an outcome
Negotiable — The user story is not an outcome but an invitation to a conversation
Valuable — The user story should demonstrate the value of the product
Estimable — If you cannot estimate it, how are you going to schedule it ?
Small — Small user stories are manageable
Testable — If there is no way to agree to it’s finality, then how can it be considered done?
Some teams adopt the practice of creating INVEST templates and add them as a point of reference in an internal wiki. Writing requirements to consistently fit the INVEST criteria can be especially difficult for a project stakeholder new to the practice. The perception of what the individual areas in the criteria mean may differ from team to team. To have clarification, the meaning of INVEST can be added to the working agreement for the Agile software team.