A user story is a short, plain-language description of a piece of functionality, written from the point of view of the person who will use it. It captures who wants something, what they want to do and why it matters to them. The most common format is âAs a [type of user], I want [some goal] so that [some benefit]â. User stories come from Extreme Programming and are now a standard way of expressing requirements in agile teams. They usually sit in a product backlog and are refined, estimated and split until theyâre small enough to deliver within an iteration.
A user story isnât a full specification. Itâs often described through the âthree Csâ:
- the Card, the brief written story
- the Conversation, the discussion between product, development and testing that fills in the detail
- the Confirmation, the acceptance criteria that show when the story is done
Many teams also check stories against INVEST: Independent, Negotiable, Valuable, Estimable, Small and Testable.
So what? User stories give testers an early way into the work. Because each story states a user, a goal and a benefit, testers can question assumptions, spot missing scenarios and shape acceptance criteria before any code is written. A story that canât be tested is usually a sign that the goal or the benefit isnât clear yet.
Examples: âAs a returning customer, I want to save my delivery address so that I donât have to type it in every time I order.â The acceptance criteria might cover the following:
- editing a saved address
- holding more than one address
- what happens when a saved address is no longer valid for delivery
A story thatâs too large, such as âAs a shopper, I want to manage my accountâ, is often split into smaller stories for passwords, addresses and payment details.
