Acceptance criteria

Acceptance criteria are observable conditions of done—they connect user behavior, system state, validation rules, analytics, accessibility, and rollback expectations. Good criteria are testable without guessing intent.

					Given an admin on the billing page
When they export usage for last month with no rows
Then they download a CSV with headers only
And see an inline message that no usage was recorded
And an analytics event "export_empty" fires
				

| Weak | Strong | |------|--------| | "Export works" | Named roles, formats, limits, empty and error UX | | "Fast enough" | p95 under X ms on staging with N rows | | "Secure" | Unauthorized users receive 403 and no file URL |

On interviews: rewrite vague criteria into Given/When/Then or a checklist QA can execute. Mention how criteria map to automated tests.

Common pitfalls: subjective adjectives; criteria that require production-only verification; missing rollback or feature-flag behavior.

The trade-off is upfront specificity versus agile discovery—criteria should still allow thin slices with explicit deferrals.

Checklist:

• Observable user and system outcomes.
• Cover error, empty, and unauthorized paths.
• Tie to tests, analytics, or monitoring where relevant.
• State what is deferred to a later slice.