Well, a User Story is basically what the user is required to perform as a part of his job responsibilities. It gets the data of who, what and why pertaining to a prerequisite in a simple and conscience way on a notecard made of paper. User Stories are written by or for the business user and could also be written by the developer. User Stories are easy way of taking care of customer requirements without the need to make formal requirement document and without the need to perform tasks which are about administering and maintaining them. Faster response in a much more economical way to the dynamics of ever altering requisites of reality forms the prime intention of User story.
Basically, a User Story is a casual document of the requisites in case of absence of communication toward acceptance testing processes. An acceptance procedure needs to be transcribed by the customer for making sure through testing or any other methods for realizing the fulfillment of objectives pertaining to the user story, before its inception.
There are many benefits of using user story:
- Good communication
- Corruption of information does not happen
- Makes it easy to estimate the development effort
- Needs less Maintenance
- Have a 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.
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. Instead of having the requirement like this the user story is the service users must be able to drag the service cart anywhere in the building without any obstruction so that the service cart is used by all the occupants.
