Many disagreements in software projects come down to one question: is this finished? Acceptance criteria answer that question in advance by describing, in testable terms, what a feature must do to be accepted.
What acceptance criteria are
Acceptance criteria are specific conditions a feature must meet. They are written before development, agreed by both sides and used to test the result. They describe behaviour, not implementation.
A simple format
A widely used format describes a situation, an action and an expected result:
Given a sales officer has entered all required order details, when they submit the order, then the order is saved, given a reference number and shown in the supervisor’s approval list.
Good criteria are testable
Compare these two statements:
- “The search should be fast.” This cannot be tested objectively.
- “Search results for a product name appear within two seconds for a typical query.” This can be checked.
Avoid words like “user-friendly”, “quick” or “intuitive” unless you define what they mean.
Cover the important cases
For each feature, consider:
- the normal, expected path;
- invalid input, such as missing or incorrectly formatted fields;
- permissions: who can and cannot perform the action;
- boundaries, such as maximum values or empty lists;
- what happens when something fails, such as an unavailable integration.
Keep them proportionate
Not every button needs ten criteria. Focus detail on features that are complex, high-risk or likely to be interpreted differently.
Agree them together
Acceptance criteria work best when written jointly by the people who understand the business need and the people building the solution. The conversation often reveals assumptions that neither side had stated.
Use them throughout delivery
- Developers use them to understand what to build.
- Testers turn them into test cases.
- Clients use them during acceptance testing.
When requirements change, update the criteria so they continue to reflect the agreed scope.
The benefit
Clear acceptance criteria turn “I expected something different” into a specific, discussable gap, and make sign-off a straightforward check rather than a negotiation.
