Writing effective acceptance criteria
Good acceptance criteria are specific, verifiable, and complete. This guide shows how to write criteria that lead to accurate verification.
Be specific
Vague criteria can’t be reliably verified.
Too vague:
-[ ] Endpoint is secureSpecific:
-[ ] Requires authentication via Bearer token
-[ ] Returns 401 for missing or invalid token
-[ ] Returns 403 if user lacks permissionToo vague:
-[ ] Handles errors properlySpecific:
-[ ] Returns 404 if resource not found
-[ ] Returns 503 if downstream service unavailable
-[ ] Error responses include correlation IDInclude both positive and negative requirements
Say what should happen and what shouldn’t.
Negative requirements often catch bugs that positive requirements miss.
Cover error cases
Don’t just test the happy path.
Think about what could go wrong and how your code should respond.
Add performance requirements only when meaningful
Only include these if they’re actual requirements. Don’t add “P99 under 100ms” to everything just because it sounds good.
Express constraints as criteria
Things that must not happen:
Use concrete values
Vague:
Concrete:
Vague:
Concrete:
Group related criteria
For readability, group criteria by concern:
Common patterns
REST endpoint
Data mutation
Integration
Criteria to avoid
Implementation details:
Better to focus on behavior:
Subjective judgments:
Compound criteria:
Split into separate criteria:
See also
Last updated
Was this helpful?