A User Story is basically a statement of the result a user needs to perform his or her task. It tells who, what and why pertaining to a prerequisite in a simple and conscientious way often written simply on a notecard or post-it note made of paper. In Scrum, User Stories are written by the Product Owner to meet the needs of the business user and can also involve input from the entire Scrum Team. User Stories are an easy way of taking care of customer requirements without the need to make formal requirements documentation and without the need to perform tasks which are about administering and maintaining that documentation. Faster response–in a much more economical way–to the dynamics of ever changing requirements is the prime intention of the User story.
The User Story often contains basic information needed by the Product Owner to write its Acceptance Criteria–which is communicated to the Scrum Team along with each User Story. The Acceptance Criteria form the base for developing and applying any necessary testing during development and before the Story is demonstrated during the Sprint Review meeting.
There are many benefits of using User Stories:
- Good communication
- Corruption of information does not happen
- Easier estimation of development effort
- Less required documentation and its maintenance
- Positive and productive engagement 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.
Requirements often come in a form like this: the doors should be at least 3.34 foot wide and 7 foot tall, all pathways must have a clearance no less than 5.4 feet. The User Story turns this into a clear statement of what need is actually being met: “the service personnel must be able to maneuver their service carts anywhere in the building without any obstruction so that the service carts are available to all employees.” The actual measurements in meters or feet and inches may become part of the Acceptance Criteria or descriptors used by the Scrum/Development Team.
