A user story represents a small piece of business value that a team can deliver in a sprint. Though traditional requirements (like use cases) try to be as detailed as possible, a user story is defined incrementally in three stages:
Structure of a Good User Story
Who are we building it for, who the user is? — As a <type of user>
What are we building, what is the intention? — I want <some goal or objective >
Why are we building it, what value it brings for the user.? — So that <benefit, value>
Well-formed stories will meet the criteria of Bill Wake's INVEST acronym:
A. Independent - Can the story stand-alone by itself?
B. Negotiable - Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.
C. Valuable - Users or customers get some value from the story.
D. Estimable - The team must be able to use them for planning.
E. Small - Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.
F. Testable - Can this story be tested and verified?