Acceptance criteria are the conditions a piece of software must meet before the person paying for it accepts it as finished. Their importance is simple to state: without them, “done” is a matter of opinion, and the developer’s opinion and the customer’s rarely match. With them, both sides agree before work starts what will be checked at the end, and the check can be carried out by anyone.
That makes acceptance criteria the cheapest protection available on a software project. They cost a few minutes per feature to write and they prevent the most common dispute there is: “that is not what we asked for”.
What acceptance criteria are
Each piece of work on a project, often written as a user story (a short statement of something a user needs to be able to do), gets its own short list of criteria. Each criterion is a statement that is either true or false when you look at the finished software.
They are often confused with three other things.
Requirements say what is wanted. Acceptance criteria say how you will tell that you have got it. “Customers can reset their own password” is a requirement. “The reset link stops working after one hour” is a criterion.
The Definition of Done applies to every piece of work, not to one. The Scrum Guide (2020) defines it as “a formal description of the state of the Increment when it meets the quality measures required for the product”: for example, that the code has been reviewed, the automated tests pass and the change is deployed to a test environment. The Scrum Guide does not mention acceptance criteria or user stories at all. They are practices that teams add to Scrum, and work is finished only when it meets both its own criteria and the team’s Definition of Done.
Test cases are the detailed steps a tester follows. Good criteria make test cases easy to write, and many teams turn criteria straight into automated tests.
Why they matter
Writing criteria forces the awkward questions to be asked before the work is built, when the answer costs nothing. What happens if the customer has no email address on file? Can a manager see other departments’ records? Asked in week one, each is a short conversation. Discovered at delivery, each is a rebuild.
They make estimates better, because the developer is pricing a list of specific behaviours and not a headline.
They give the tester, and you, something to test against. Without criteria a tester can only check that the software does what the developer intended, which is not the same as what you wanted.
They limit scope in both directions. Work that meets the criteria is finished, so the developer does not gold-plate it. A request that is not in the criteria is new work, so it is discussed and priced openly and does not slip in unnoticed.
Acceptance criteria and fixed-price work
A fixed price is a price for a defined result, and acceptance criteria are the definition. This is why we say that fixed-price software development works when the scope and the acceptance checks are agreed first. The quotation prices the criteria. Delivery is measured against the criteria. A change to the criteria is a change request, assessed and quoted before anyone acts on it.
If a supplier offers a fixed price against a description with no acceptance checks, there are only two outcomes. Either the supplier decides what “finished” means, or the two of you argue about it at the end. The criteria also need a named person on your side with the authority to say yes, and an agreed period in which to do the checking. Our fixed-price page describes how scope, price and acceptance checks are agreed before our own projects start.
How to write good acceptance criteria
There are two common formats, and most teams use both.
A checklist suits rules and limits. For a feature that exports unpaid invoices to an accounts package:
- Only invoices with a status of Approved and an unpaid balance are exported.
- An invoice that has already been exported is not exported again.
- If the accounts package rejects an invoice, the user sees which one and why, and the other invoices are still exported.
- A user without the Finance role cannot see the export button.
- An export of 500 invoices completes in under one minute.
Given, When, Then suits behaviour that depends on a sequence. It comes from behaviour-driven development and is the format used by the testing tool Cucumber. Given sets the starting situation, When is the action, Then is the expected result:
- Given an invoice that was exported yesterday, when the user runs the export again, then that invoice is not sent a second time.
Whichever format you use, the same qualities separate useful criteria from decoration.
| Weak criterion | Why it fails | Better |
|---|---|---|
| The search should be fast | Nobody can say whether it passed | Results appear within two seconds for a customer list of 50,000 |
| Users can filter results | Does not say by what | Results can be filtered by date range, status and account manager |
| Click Submit to save the form | Dictates the design, not the outcome | A completed form is saved and the user sees a confirmation |
| The system handles errors | No error is named | If the postcode is not recognised, the address fields can be typed by hand |
A few rules follow from that table:
- Describe the outcome, not the screen. Leave the developer free to find the best way to achieve it.
- Cover what happens when things go wrong. Missing data, duplicates, a user without permission and a failed connection are where most defects are found.
- Include the qualities as well as the functions. Speed, security, who can see what, and how many records it must cope with are called non-functional requirements, and they need a number wherever one is possible.
- Use the words your staff use. If the business says “job” and the criteria say “work order entity”, the person approving them will not spot the mistakes.
- Keep the list short. More than eight or so criteria usually means the piece of work should be split.
Who writes them, and when
The person who understands the business need should write the first draft: the product owner, the operations manager, whoever will be asked to approve the result. The development team then challenges it. Their questions are valuable, and the answers go into the criteria. A tester’s view at this stage is worth having too, which is one reason to start testing early.
The timing rule is strict: criteria are agreed before work on the item starts. Criteria written after the software exists tend to describe what was built.
At delivery, the developer shows each criterion being met, and the approver signs off or names the criterion that failed. Anything else the approver would like is a new request.
A check you can make this week
Take the last three pieces of work your developer or supplier delivered. For each one, find what was written down before the work started and ask whether a colleague who was not involved could use it to decide if the work was finished. If they could not, ask for acceptance criteria on the next piece of work before it begins. For a new project, our project planning worksheet asks for the five things the system must do on day one, each written as something a person does, which is a good starting point for criteria. If a current project is already in dispute over what was agreed, our project rescue page describes how we assess what has been built and finish it against agreed acceptance checks.