User stories and acceptance criteria (Given-When-Then)

A user story is a lightweight way to capture a requirement from the perspective of the person who benefits. The standard template, popularized by Mike Cohn and originating from Connextra, is: 'As a <role>, I want <action>, so that <value>.' Each part serves a purpose: the role anchors who needs the feature, the action states what they need to do, and — crucially — the 'so that' clause explains the business value or outcome. Teams that skip 'so that' risk building features no one actually needs. Acceptance criteria make a story testable. The most widely used format is Given-When-Then (also known as Gherkin): Given describes the context or precondition before the action happens; When describes the specific trigger or action the user takes; Then describes the observable, verifiable outcome. A well-written 'Then' must be objectively checkable — not 'the system responds quickly' but 'the system displays the order confirmation page within 2 seconds'. A healthy user story typically has one to three acceptance criteria. Too many criteria often signal the story should be split. The Given-When-Then format is not just documentation — it can be turned directly into automated tests, which is why developers and testers value it as much as analysts do.