User stories are the best-known tool of agile requirements work and one of the most misunderstood. A good story is not a shortened specification but the occasion for a conversation, recorded so that in the end it can be verified whether the goal was met.
The structure
The classic pattern reads: As a role, I want to achieve a goal, so that a benefit arises. For example: As an accountant, I want to filter open invoices by due date, so that I send reminders in time. The role forces a change of perspective, the goal describes the what without the how, and the benefit explains why the story matters at all — it is the basis for prioritisation.
Good stories: INVEST
A proven checklist is INVEST: independent of other stories, negotiable in detail, valuable for users or customers, estimable, small enough for a sprint and testable. Stories that are too large are split along the benefit, not along technical layers: better a filter by due date first, then one by customer, than first the database, then the interface.
Acceptance criteria
Acceptance criteria describe concretely how you recognise that the story is fulfilled. A common format is Given-When-Then: given three invoices with different due dates; when the accountant filters for overdue; then only invoices due before today are shown. Good criteria also cover edge and error cases and are phrased so that they can be tested automatically.
Difference from the definition of done
Acceptance criteria apply to a single story. The definition of done applies to all: code reviewed, tests written, documentation updated, deployed. A story is only done when both are met. Mixing the two means repeating the same criteria in every story or forgetting the general quality requirements.
Common mistakes
Stories from the system’s perspective instead of the user’s. Roles like “As a user” that say nothing. A missing benefit. Acceptance criteria that only emerge during implementation. And stories that are really technical tasks. In regulated or public projects, for example under HERMES, stories are often combined with formal requirements; how to do that cleanly is described under requirements engineering.