User stories and acceptance criteria: Formulating requirements clearly

In short: A user story describes a requirement from the user’s perspective in one sentence; acceptance criteria define when it counts as fulfilled.

In more detail: Long specifications are often not read. Agile teams write requirements as short stories that show benefit and purpose and are made concrete in conversation.

In Depth

The format

As a I want so that . Example: “As a customer I want to receive my order confirmed by email so that I know it has arrived.” The three parts answer Who? What? Why? The “so that” prevents functions without purpose. The story is not a complete contract but an occasion for conversation.

Good stories: INVEST

• Independent
• Negotiable
• Valuable (to user/customer)
• Estimable
• Small (small enough for a sprint)
• Testable Too large stories (“epics”) are split into smaller ones.

Acceptance criteria

They describe concretely when the story is done, ideally in given – when – then format:

• Given the cart is not empty, when I pay, then I receive a confirmation email with order number.
• Email arrives within 5 minutes; contains items, total, delivery address.
• For an invalid email address an error message is shown. They are testable (yes/no), complete enough and form the basis for tests (see BDD) and acceptance.

Embedding in the project

Stories sit in the product backlog, are prioritised and implemented in the sprint. The definition of done (DoD) applies to all stories (code reviewed, tests green, documented, deployed), the acceptance criteria to one story. In the IHK documentation you can present requirements as user stories with criteria and complement requirements/specification documents. Additionally: use case diagrams, prototypes, sketches.

See also: Agile methods, Requirements and specification documents, BDD, Acceptance and handover