Acceptance criteria guide
How to write acceptance criteria
Acceptance criteria define when a feature is done. Written well, they eliminate guesswork for developers, give QA a clear target, and prevent the endless “is this done?” debate.
What are acceptance criteria?
Acceptance criteria are specific conditions that a feature must meet to be accepted by the Product Owner. They bridge the gap between user stories and what developers actually build.
Why they matter
Without clear acceptance criteria:
Two formats
Pick the format that matches the complexity of what you’re describing. Both are valid; use them in combination on the same ticket if it helps.
Checklist
Simple bullet points. Good for straightforward features where the behavior is clear without needing to spell out context or triggers.
Given / When / Then (Gherkin)
Behavior-driven. Great for complex flows and QA automation. Forces you to spell out the starting state, the action, and the expected result.
The format
GIVEN [initial context]
WHEN [the action or event]
THEN [the expected outcome]
What makes a good acceptance criterion
Good acceptance criteria share four properties. Check each one before adding criteria to a ticket.
Testable
Can a QA engineer write a test case from it? If yes, it is good.
Specific
‘User can see their profile’ is bad. ‘User can see their display name, photo, and email on the profile page’ is good.
Outcome-focused
Describes what happens, not how it is built.
Edge cases covered
What happens when the input is empty? Too long? The network is down?
Common mistakes
Most weak acceptance criteria fall into one of three patterns.
For your role
Acceptance criteria are a shared responsibility, but each role has a different job to do with them.
Next steps
Apply in the Agile workflow
See how acceptance criteria fit into sprint planning, backlog refinement, and the definition of done inside a real Agile team.