A User Story is a simple way of recording what a user is required to perform as a part of his or her job responsibilities. It gets the data of who, what and why pertaining to a requirement in a simple and conscientious manner. User Stories are written by or for the business user and can also be written by the Scrum Team. They are an easy way of recording customer requirements without the need for a formal requirements document and without the need to plan processes for administering and maintaining requirements. Faster response in a much more economical way aligned to the dynamics of ever altering requisites of reality forms the prime intention of the User Story.
A User Story is a casual document of requirements that can be used to develop acceptance criteria. Acceptance criteria are usually determined by the Product Owner in partnership with the customer for use during the Sprint Review meeting to make sure each deliverable meets the customer’s needs before implementation.
There are many benefits of using User Stories:
- Encourages good communication
- Prevents corruption of information
- Makes it easy to estimate the development effort
- Needs less Maintenance
- Enables close contact with the customer
User Story Format:
As a <role/persona>, I should be able to <requirement> so that <benefit>.
User Story Example:
As a Database Administrator, I should be able to revert a selected number of database updates so that the desired version of the database is restored.
Instead of having the requirement like this: the doors should be at least 3.34 foot wide and 7 foot tall, the pathways must have a clear way of at least 5.4 feet, a User Story express the need tis way: resident service personnel must be able to transport the service carts already in use anywhere in the building without any obstruction so that the service cart is used by all occupants.
