The project requirements in a process using agile methodologies can be understood and expressed as user stories. A user story is a simple description of a product requirement in terms of what that requirement must accomplish for whom.
At a minimum, a user story has four components or statements:
A user story also includes validation steps — steps to take to know that the working requirement for the user story is correct: When I
User stories may also include:
A user story ID: A number to differentiate this user story from other user stories.
The user story value and effort estimate: Value is how beneficial a user story may be to the organization creating that product. Effort is the ease or difficulty in creating that user story.
The name of the person who thought of the user story: Anyone on the project team can create a user story.
A typical user story card with the front showing the main description of the user story. The back shows how to confirm that the requirement works correctly, after the development team has created the requirement:
User stories aren't the only way to describe product requirements. You could simply make a list of requirements. However, because user stories include a lot of useful information in a simple, compact format, they're very effective at conveying exactly what a requirement needs to do. The big benefit comes in when the development team starts to create and test requirements. The development team members know exactly whom they are creating the requirement for, what the requirement should do, and how to double-check that the requirement satisfies the intention of the requirement.
