How to write acceptance criteria that testers and business owners agree on
Most disputes at UAT are really disagreements about what "done" meant, and nobody wrote it down in a form both sides could check. Acceptance criteria are where that agreement lives. When they are vague, the tester reads one thing, the business owner expects another, and you spend the last week of the sprint refereeing.
This article shows what weak criteria look like, how to rewrite them, and where Given/When/Then helps and where it just adds length. The example is a fictional firm, Northgate Bank, and a story about handling payment instructions that arrive late.
Last reviewed: October 2026.
What acceptance criteria are for
They answer one question: how will we know this story is finished? Each criterion should be something a tester can check and a business owner can read without a translator. If either of them has to ask what a word means, the criterion is not finished.
They are not a design document, and they are not a list of everything the system does. They cover the behaviour that matters for this story.
Three weak criteria and why they fail
Take the story: "As an operations analyst, I want late payment instructions handled automatically, so that I do not release them by hand."
"The system handles late instructions correctly." Correctly according to whom? A tester cannot fail this, so it tests nothing.
"Late instructions are processed quickly." Quickly is a feeling. Ten seconds and ten minutes could both be quick, depending on who is asked.
"The system rejects invalid instructions." Invalid in which way? A missing field, a closed account, a breached limit? Each needs its own expected result.
The common fault is that each one hides a decision. Somebody has to say what "late" means, what "processed" means and what happens next. Your job is to drag those decisions into the open.
Starter, £30 (41 files, discovery to a tested set of requirements) · Complete, £80 (59 files, adds governance and assurance). Prices include UK VAT: Starter £25 + VAT, Complete £66.67 + VAT. Payhip may show the price before VAT. One payment, no subscription.
Sold by Quantum Sphere Consulting Limited; your statutory rights apply.Rewriting them
Start by asking the owner the awkward questions. For Northgate the answers were: the cut-off for same-day payments is 15:30 on a business day; anything received after that goes into the next business day's batch; the sender gets a notification; nothing is rejected for lateness alone. Whether that is true for a real scheme is a matter for the real rulebook. Here it is the invented rule, and each answer has a source in the project register (S-014, the operations procedure).
Now the criteria become checkable:
- An instruction received at 15:30:00 or earlier on a business day is included in that day's batch.
- An instruction received after 15:30:00 is included in the next business day's batch.
- An instruction received after 15:30:00 on a Friday is included in the Monday batch, unless Monday is a bank holiday, in which case it goes into the next business day.
- The sender receives a "scheduled for next business day" notification within five minutes of receipt.
- An instruction is never rejected solely because it arrived after cut-off.
A tester can pass or fail each line. An owner can read each one and say yes or no.
When Given/When/Then helps
Given/When/Then is useful when the behaviour depends on a starting state. It is less useful for simple rules, where a plain sentence is shorter and clearer.
The format is: Given a starting condition, When something happens, Then an observable result. Here it is applied to the same story:
| # | Given | When | Then |
|---|---|---|---|
| 1 | The time is 15:29 on a business day | A valid instruction is received | It is placed in today's batch |
| 2 | The time is 15:31 on a business day | A valid instruction is received | It is placed in the next business day's batch and the sender is notified |
| 3 | The time is 16:00 on Friday and Monday is a bank holiday | A valid instruction is received | It is placed in the Tuesday batch |
| 4 | The time is 15:31 | An instruction with a closed debit account is received | It is rejected with reason code "account closed", not "late" |
| 5 | The notification service is unavailable | A late instruction is received | The instruction is still scheduled and the failed notification is logged for retry |
Rows 3 to 5 are the ones a rushed team misses. Row 4 separates two failure reasons that are easy to confuse. Row 5 covers what happens when something around the story breaks.
A quick test for each criterion
Before you hand criteria over, check each one against these questions:
- Can it fail? If every outcome passes, rewrite it.
- Does it contain a number, a time, a state or a named message in place of an adjective?
- Does it say who or what acts, in the present tense?
- Is there one behaviour per line?
- Could a tester run it without asking you what you meant?
Getting agreement, not just writing
The words matter less than who has read them. Sit with the tester and the owner together for twenty minutes and read the criteria aloud. The tester will say "how would I set that up?" and the owner will say "no, that is not what happens on a holiday". Both comments improve the criteria far more than another round of editing alone.
Record any change with the person who asked for it. If an owner adds a rule in the meeting, note it with their name and mark it proposed until they confirm it in writing.
Common mistakes
Writing the solution. "The batch job runs at 15:31" is a design choice. The criterion is about what the sender and operations see.
Leaving out the negative case. Every positive rule has a side where it does not apply. State it.
Too many criteria on one story. More than eight usually means two stories.
Copying criteria between stories. The same line in three places will drift. Link to one version.
Try it
Choose one story from your current backlog and mark every adjective in its criteria. Replace each with a value, a state or a message, and ask the owner to confirm the ones you had to guess.
The Starter toolkit includes a User Story and Acceptance Criteria Library with worked examples.