On this page
Acceptance criteria define the behavior that must be true before a piece of software is accepted. They give developers, reviewers, and product owners a shared basis for deciding whether the work meets its purpose. A criterion is useful when it can distinguish a working outcome from an implementation that merely looks plausible.
Start with the user task and the relevant operating conditions. Then describe the observable result. The criteria should be specific enough to verify, while leaving room for appropriate design and engineering choices where those choices do not change the required behavior.
Write the starting state before the action
The same action can produce different correct results depending on the state of the system. A person submitting a valid new request is different from a person retrying a request whose previous outcome is uncertain.
For a fictional room-booking service, identify whether the person is signed in, whether the room is available, and whether they have permission to make the reservation. These conditions affect the expected result and the evidence needed to review it.
Do not make reviewers guess which setup you intended. A concise criterion can state the relevant condition directly: an authorized requester with a valid time range can submit a request for an available room and receive a reservation reference.
Describe the result in terms the user can observe
“The API returns success” may establish one technical behavior, but it does not prove that the user knows the reservation exists. The interface may show the wrong status, omit the reference, or fail to preserve the result when the page reloads.
State the complete result that matters. The requester sees the confirmed room and time, can return to the reservation, and receives the next-step information required by the service. Supporting technical checks can then verify how that result is stored and protected.
Avoid criteria that only name code artifacts. The existence of a component, database field, or function does not establish that the intended person can complete the task through the real entry point.
Use a small example matrix
Examples make boundary decisions easier to review. The following matrix is illustrative; a real booking service needs criteria based on its own rules and risks.
| Situation | Expected behavior | Evidence to inspect |
|---|---|---|
| Valid request for an available room | One reservation is created and shown clearly | User confirmation and stored record |
| End time precedes start time | Submission is prevented with a useful correction | Error text, focus behavior, preserved input |
| User lacks permission | Restricted action is rejected without exposing private details | Interface and server-side access result |
| Connection fails after submission | The user can determine the actual outcome without blind resubmission | Recovery path and duplicate protection |
| No rooms match the search | The page explains the valid empty result | Empty state and available next action |
The matrix separates several meanings that a generic “booking works” statement would hide. It also identifies where evidence must come from more than a screenshot.
Distinguish empty results from failed results
An empty list can mean that no records match the request, or that the system failed to load the records. Those states should not be presented as equivalent when the difference affects a decision.
In the booking example, a failed availability request must not imply that every room is unavailable. Likewise, a support dashboard that cannot load urgent cases should not show “zero urgent cases” as though that were a verified result.
Write criteria for the distinction when it matters. The correct next action may be to retry, wait, contact support, or use another process. Choose the behavior according to the service instead of applying the same generic error message everywhere.
Include access and data boundaries
Identify who may read, create, change, or remove the relevant information. A hidden button is not enough if a direct request can still perform the restricted action. Acceptance evidence should include the enforced boundary as well as the visible interface.
Use appropriate test accounts and non-sensitive fixtures. A review should not require copying real customer records into a shared document or granting reviewers broader production access than they need.
Consider the information shown in errors and notifications. A rejection should help an authorized user understand the next step without revealing another person's private record, an internal secret, or unnecessary system details.
Make accessibility part of the task
Describe the important interaction in a way that includes relevant input and assistive methods. A form that can be submitted only with a mouse has not necessarily met the intended task for keyboard users. A validation message that is visible but not communicated appropriately may leave another user without a way forward.
Use the applicable accessibility standards and product requirements to define the review. Automated checks can identify some issues, but they do not establish that the complete journey is understandable and usable.
Keep criteria proportionate to the change while preserving the important user route. If a new modal interrupts the booking flow, review how focus enters and leaves it, how it is dismissed, and whether the user can continue. The exact checks depend on the design.
Separate acceptance criteria from the full test plan
Acceptance criteria explain what must be true. A test plan explains how the team will gather sufficient evidence across relevant devices, data, integrations, and failure conditions. The two should connect without becoming identical documents.
For example, a criterion may require a recoverable response to an unavailable dependency. The test plan can specify how that failure is simulated in a controlled environment and what records establish that no duplicate action occurred.
Avoid expanding a small change into an unbounded test inventory. Add checks that resolve a concrete risk or satisfy a required gate. Repeating many shallow checks is less useful than verifying the important boundary accurately.
Define who can accept a tradeoff
Sometimes the implementation meets the main outcome but has a known limitation. Record the limitation clearly and identify the person authorized to accept it. A developer's completion note should not silently change the agreed requirement.
Distinguish a minor visual issue from a missing core behavior or an unresolved security boundary. The release decision should reflect the actual impact, not the number of tickets remaining.
When a criterion changes, update the current requirement and explain the reason. Do not preserve an impossible criterion in the document while informally telling reviewers to ignore it. That creates conflicting definitions of completion.
Review evidence through the real entry point
Demonstrate the task as the intended user would reach it. A hidden development route or manually prepared database state may help isolate a component, but it does not prove the full production journey is available.
Record the version or build reviewed, the relevant setup, the observed result, and any remaining limitation. Keep the evidence concise enough to inspect. A long log with no explanation of the expected outcome can be harder to assess than a focused result.
Acceptance criteria have succeeded when the team can explain why the behavior is ready and where its limits remain. The goal is a shared, evidence-backed decision about the user outcome, not a checklist whose boxes can be ticked without opening the product.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- GOV.UK Service Manual: Writing user stories Acceptance criteria describe the outcomes that confirm a service meets the user need.
- W3C: Evaluating web accessibility Accessibility evaluation includes human judgment and user experience; automated tools alone cannot establish complete accessibility.