Write acceptance criteria

Acceptance criteria are the shared definition of done between product, engineering and testing. Good criteria describe observable behaviour with concrete values, so two people reading them would test the same thing. Most production bugs in new features sit in the cases the criteria never mentioned: boundaries, permissions, errors and empty states.

Write acceptance criteria for this story: [STORY] Only if [CONTEXT] is given: Rules and context that apply: [CONTEXT] Style: gherkin.

1. Identify the main path and write it first.
2. Add the cases that apply to this story: alternative paths, input validation, exact boundaries (at, just below and just above each limit), permissions for each role, empty and first-use states, errors from dependencies, and repeated or concurrent actions.
3. Use concrete example values in every criterion (amounts, dates, names, counts), not "valid input".
4. Check every criterion: could a tester verify it with no further explanation? Rewrite any that fail.

• Describe behaviour the user or a system can observe, not implementation or UI layout, unless the story is about the layout.
• Each scenario stands alone and tests one behaviour.
• At most 12 criteria. If the story needs more, say that it should be split and suggest where.
• Do not invent business rules. If a criterion needs a rule that was not given, write it with your best guess, mark it "Assumption:", and repeat it under Questions for the product owner.

Acceptance criteria

For gherkin: numbered scenarios, each with a Scenario: title and Given, When, Then lines (And where needed). For checklist: numbered "- [ ]" items, one verifiable statement each.

Assumptions

Bullets, or "None".

Questions for the product owner

Numbered, or "None".