Turning vague requests into acceptance criteria
Updated
From 'make it better' to given-when-then: the translation technique that ends scope arguments before they start.
Vague requests are not a customer failure; they are the raw material. Your job is the translation into sentences a stranger could test.
The short answer
Rewrite every wish as given-when-then with a numeric threshold. If you cannot, the request is not scoped yet.
The translation table
| Vague | Testable |
|---|---|
| "Fast lookup" | "Given a return label, when scanned, then the order shows in under 3 seconds for 95 of 100 scans" |
| "Reliable sync" | "Given 10,000 source rows with 2 percent duplicates, when synced, then zero duplicates land and the error report lists every dropped row with a reason" |
| "Secure access" | "Given a user from team B, when querying team A documents, then zero rows return, verified by 4 adversarial probes" |
| "Good handover" | "Given the runbook, when the on-call engineer follows it for the top 3 symptoms, then recovery completes without calling the author" |
Worked example: the practice task
The p07 practice task asks for five measurable given-when-then criteria from five vague product wishes. The pass criteria are published: numeric threshold in each, given-when-then shape, no vague adjectives. Do it once and the reflex transfers to every brief you ever write.
Checklist: criteria that hold
- A stranger could run the test without asking you anything.
- Every adjective has a number attached.
- Failure is defined, not just success.
- Both sides signed the list.
Related reading
Straight answers
Frequently asked questions
What does good acceptance criteria look like?
Given-when-then with a number: context, action, measurable outcome. 'Fast' is not a criterion; 'under 3 minutes for 9 of 10' is.
Who writes the criteria?
You draft, the customer corrects, both sign. Criteria dictated by one side get gamed or ignored.
How many criteria per slice?
Three to seven. Fewer means the slice is fog; more means the slice is two slices.