What Is Acceptance Criteria? How to Write Conditions Everybody Agrees On

Acceptance criteria are the conditions a piece of work has to meet before anybody calls it done. They are written before the work starts, by the person asking for it, and agreed with the people who will build and test it.

Their job is to move an argument forward in time. Without them, “is this finished?” gets settled after the work, by whoever feels most strongly. With them, it was settled before, by people who were calm.

What they are not

Not a description of the feature. “The user can filter the report” is a summary. A criterion says what must be true: which filters, what happens when none match, what the state is after a reload.

Not a design. Criteria describe outcomes, not layouts. “A dropdown at the top right” decides the solution and takes it away from whoever is best placed to choose it.

Not test cases. A criterion is a condition; a test case is a procedure for checking one. Several test cases usually hang off a single criterion, and they are written later, by somebody who may not be the same person.

The two formats people use

A checklist is the plainer of the two, and it is enough for most work.

Done when:
- A signed-in user sees only their own orders
- An order with no items still appears, with a total of 0.00
- The list loads within two seconds for an account with 10,000 orders
- Sorting by date holds across pagination

Given, when, then is more formal, and it earns its extra ceremony when the behaviour depends on state.

Given a customer with an expired card
When they submit the checkout form
Then the payment is refused
And the card fields keep the values they entered
And the message says which field to correct

The value is in the given. Most misunderstandings live in the starting state - a trial account, an expired token, an empty list - rather than in the action, and the format forces somebody to name it.

Neither format is better. Use the checklist by default and reach for given-when-then where the same action has to behave differently depending on the situation.

What separates a good criterion from a bad one

The test is whether two people could disagree about whether it is met.

Weak

The page should load quickly and show relevant results

Better

The first page of results appears within two seconds for an account with 10,000 orders, and shows only orders that account owns

Four habits produce most of the weak ones:

• Adjectives instead of thresholds. Fast, intuitive, robust, user-friendly. None can be checked; all can be argued about.
• Only the happy path. Criteria that describe what happens when everything works leave every failure to somebody’s judgement at four in the afternoon on release day.
• Solutions. “Add a confirmation modal” instead of “the user cannot delete an invoice without confirming”.
• Everything at once. A story with nineteen criteria is several stories, and it will be half-done for a fortnight.

Who writes them, and when

Whoever is asking for the work drafts them, and they are agreed before anybody starts. That is the part teams skip, and skipping it is what turns a two-day task into a week of clarification.

It does not have to be heavy. A developer reading the draft and asking “what should happen if they have no orders yet” is the whole process working: the question is cheap now and expensive after the code exists.

Write them down where the work lives, not in a chat message. Criteria that only exist in somebody’s memory of a meeting produce exactly the argument they were meant to prevent.

Where they end up mattering

Two places, and they are the reason it is worth the effort.

Acceptance testing. The people running user acceptance testing need something to accept against. Without criteria, UAT becomes a survey of opinions about software somebody has already paid for.

Bug triage. The most tedious argument in software is whether something is a defect or a change request, and it is decided by what was agreed. A defect is behaviour that contradicts a criterion; anything else is a new request, however reasonable. Teams without written criteria have that argument once per release, forever.

That is also why a report of a defect should say what was expected as well as what happened - it is the same sentence as the criterion it contradicts.

The bug report guide covers the rest of what that report needs, and its template has a line for the expected behaviour.

The short version

Conditions, written before the work, agreed by the people who asked for it and the people who will build it, specific enough that two people cannot disagree about whether they are met. A checklist is usually enough; given-when-then when the starting state decides the outcome. Cover what happens when things fail, not only when they work.