What it means
A small business asks a developer to add a customer search screen. The request sounds simple, but one person expects search by name while another expects search by invoice number.
Acceptance criteria make the expected behaviour explicit before anyone calls the change complete. The Scrum Guide describes a Definition of Done as the shared quality standard for a product increment, whereas acceptance criteria are specific to one item or request.
Neither idea makes a particular template mandatory for every project. The useful habit is agreeing in advance what will be checked.
Good criteria start with the user's need and then break it into single, testable conditions. "Search returns only the matching customers the user is allowed to see" can be tested, but "search is user-friendly" cannot without a defined test.
A sentence that combines speed, design, access and security is hard to pass or reject cleanly. Criteria should also cover boundaries and failure.
A result that works for one record may fail with an empty list, duplicate names or a disabled account. If a service is unavailable, the criteria should say whether the user sees an error message or a retry option, because silent failure should not pass simply because the happy path works.
Roles and timing matter as much as wording. Name the person who can sign off, such as a product owner, customer representative or quality reviewer, and agree the criteria before the build or purchase starts.
Late changes can be legitimate, but they should be recorded with their effect on cost and time and not slipped into the test list. Finally, acceptance is not the same as completion.
A team may finish development yet still await customer testing, and the contract may define when legal acceptance occurs. A passed checklist also cannot prove the whole product is safe or useful, so shared standards for security, accessibility and performance still apply.
In practice
Real-world examples.
Example
A software team agrees that searching by invoice number must return only customers the signed-in user is permitted to view, and that an empty search shows a clear message and not a blank screen.
Example
A marketing agency agrees that a delivered report export must keep the agreed column names and cover the requested date range, and the client checks these two points before approving the invoice. Any mismatch is raised while the work is still fresh and easy to fix.
Example
A construction contract states that a finished floor must be level to a stated tolerance and pass the inspector's check before the final payment is released. Both sides know in advance what a pass looks like, which reduces the risk of a payment dispute.
Formula
Calculation
Criteria pass rate = criteria passed / criteria applicable x 100
Worked example: a delivery has 10 applicable criteria and 9 pass, so the pass rate is 9 / 10 x 100 = 90%. The remaining criterion, for example a missing error message, stays open until it is fixed or formally waived.
The score is only a progress indicator. Acceptance depends on the agreed conditions, so a single failed security or legal criterion can block sign-off even when most other criteria pass.Case study
Seen in the real world.
This entirely fictional example follows Cedar Services, an invented firm that asked a contractor for a customer search feature. The first delivery searched only by name, and the contractor argued it met the request, while Cedar had expected invoice numbers as well.
The two sides then agreed three specific criteria covering search fields, empty results and permissions, tested them with sample accounts and documented the sign-off. The illustrative case shows the value of clarifying expectations early, and it is not a legal view on when acceptance occurs.
Cedar also added a short template for future requests, listing the user need, the single conditions to test, the person who signs off and the evidence to keep. The next change request took one review meeting and no rework.
Watch out
Common mistakes.
- Writing vague criteria such as "easy to use" with no test, which leaves both sides arguing about taste.
- Adding new requirements after delivery without change control, which turns the review into a dispute over scope.
- Treating a passed feature checklist as proof that security and quality standards were also met.
Questions
People also ask.
What are acceptance criteria?
They are observable conditions that a specific deliverable must meet before an agreed reviewer approves it.
When should they be set?
Preferably before the work starts, with later changes recorded openly and their cost and timing agreed. Setting them late invites arguments over whether the work is finished.
Who agrees them?
The decision-maker who will sign off and the delivery team should clarify them together, so both read each condition the same way. A short walk-through of each condition with sample data often exposes differences in understanding before any work is done.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%Related