Acceptance criteria Product can actually sign
Vague “done” creates UAT fights. How I write acceptance criteria as observable outcomes, so the people who have to approve them can do it without a translator.
Acceptance criteria fail when they describe implementation instead of outcomes. “Button calls API X” is a developer note. “The customer completes a booking and receives a confirmation within 30 seconds” is something Product can own.
The first kind gets approved without being read, because the person approving cannot picture what it means for a user. The disagreement it was hiding surfaces later, in user acceptance testing, in front of stakeholders, with the release date already public. Most UAT fights are arguments about a “done” that was never shared.
What acceptance criteria are for
Acceptance criteria are the conditions a story has to meet before the person who asked for it will accept it. They have three readers. Product approves them. Engineering builds to them. QA tests against them and later puts them in front of business owners for sign-off.
A criterion only works if all three read the same thing in it. That is what I mean by criteria Product can sign: a product owner can read each line without a translator, say “yes, that is what I am asking for”, and be held to it later. Technical detail still belongs on the ticket, in the implementation notes, where it guides the build without pretending to define success.
How to write acceptance criteria as observable outcomes
I push every criterion towards something a person can observe. Starting from a user and what they are trying to do, it answers three things.
- What they should see. The screen, the message, the changed status, in words the user would use.
- What must not happen. No second charge, no email to the wrong contact, no record visible to another customer. These lines are the ones most often left out.
- What proves it. A confirmation with a reference, a row in a report, a notification that arrives. Something that can be shown to a person who was not there.
Edge cases get the same language. A declined card, an expired session and a user without the right role are all outcomes somebody will experience, so they sit in the criteria next to the happy path. Buried in a technical subtask, they are invisible to the person who has to accept the behaviour.
Format matters less than people think. Given/When/Then is a fine structure, and it is easy to write a developer note in it: given the form is submitted, when the service returns 200, then the modal closes. The test is who can verify the line. If it takes a developer with the network tab open, it is an implementation check.
Two more habits. I remove words that cannot be checked: fast, intuitive, correctly, user-friendly, as expected. And where the business has a number, the criterion carries it. If nobody knows how long a confirmation may take, that is a question for Product now and a much worse one in release week.
- WEAK: Submit button calls the booking API and returns 200.
- SIGNABLE: A customer who completes a booking sees a confirmation screen with a booking reference, and receives the same reference by email within one minute.
- WEAK: Payment errors are handled correctly.
- SIGNABLE: If the card is declined, the customer is told the payment failed, no booking is created, and they can try another card without re-entering the booking.
- WEAK: Only approvers can approve.
- SIGNABLE: A user without the approver role can open a request but sees no Approve action. The approval link opened directly shows a no-access message and changes nothing.
- WEAK: Export should be fast and user-friendly.
- SIGNABLE: A finance user can export one month of invoices to CSV. The totals in the file match the totals on screen.
The rewritten lines are longer. They are also the ones a product owner will read and correct. “Within one minute” either gets a nod or starts a conversation that was coming anyway, at a worse time.
The question to ask Product before sign-off
Before a story is committed, and again before UAT is scheduled, I walk the criteria with Product and ask one question: would you ship if only these pass?
Silence or hedging means the criteria are not ready. The hesitation is useful. It usually points at something specific: a scenario the product owner is nervous about that nobody wrote down, or an assumption about another system. I ask what they were thinking of, and that becomes the missing criterion.
Product does not have to write the criteria. Often I draft them, or a business analyst does, and Product edits. Authorship matters less than ownership: the product owner has read them, corrected them and agreed to be measured against them.
How criteria carry through testing and UAT
During testing the criteria become the spine of the evidence. Every criterion ends the sprint in one of four states, and each state links to something.
| State | What it links to |
|---|---|
| Passed | Proof: a screenshot or recording, with the build and environment it was seen on |
| Failed | A defect with a severity and a named owner |
| Deferred | The business risk in plain words, who accepted it and when it is reviewed |
| Not tested | The reason: no test data, no environment, a dependency that was not ready |
That structure keeps acceptance from collapsing into opinion. When I facilitate UAT, business owners measure the build against lines they have already read, and the same four states feed the release readiness note. Nobody has to translate test results into business terms in release week. The criteria were in business terms from the start.
Where acceptance criteria go wrong
Too many of them. A story with fifteen criteria is two or three stories. Split it. Nobody holds fifteen conditions in their head when they sign.
Treating them as the test plan. Criteria define what must be true for acceptance. They do not define everything I will check. I still explore around them, compare the build with the design it came from and try the combinations nobody listed. Behaviour the criteria never anticipated goes back to Product as a question.
Rewriting them to fit the build. When a criterion fails late, there is pressure to reword it until it passes. Criteria can change as the team learns. The change needs the person who signed the original, and a note of why.
The objection that this slows refinement. It does add minutes there. The alternative is the same conversation held in UAT, with more people in the room and less time to act on the answer.
Good criteria shorten every conversation downstream: refinement, testing, UAT and the release call. The developer knows what pass means before writing code, the tester has an oracle that is not their own opinion, and the product owner signs something they have read. The same few lines serve the user and protect the business decision.
Questions I get asked
Who should write acceptance criteria?
Anyone who understands the user outcome can draft them: a product owner, a business analyst or a tester. What matters is that Product owns them, meaning the product owner has read every line, corrected what was wrong and agreed the story will be accepted or rejected against them. Criteria that Product has not read are notes, whoever wrote them.
What makes a good acceptance criterion?
It describes an outcome someone can observe without reading code: what the user sees, what must not happen, and what record or notification proves success. It avoids words that cannot be checked, such as fast or user-friendly, and carries a number where the business has one. A product owner should be able to read it and say yes or no.
What is the difference between acceptance criteria and test cases?
Acceptance criteria state what must be true for a story to be accepted, in language Product can approve. Test cases are the specific checks a tester runs, with steps and data, and they usually go further than the criteria: combinations, neighbouring features and things nobody thought to list. Criteria define acceptance. They do not set the limit of what gets tested.
Filed under Product validation and acceptance criteria. Terms: Acceptance criteria, Definition of done, Definition of ready.
