Acceptance criteria describe the observable conditions that make a requirement acceptable. They give business users and developers a shared way to judge the result. A statement such as "the dashboard is easy to use" expresses a preference, but does not identify what someone must be able to do or how the team will verify it.
GOV.UK's user-story guidance describes criteria as outcomes that confirm a user need has been met. The practical task is to turn that principle into specific examples, including situations where the system should refuse an action.
Start with a decision the user makes
Consider a hypothetical purchasing application. The story says a department manager needs to approve a request so purchasing can place the order. Before discussing screen layout, ask what makes an approval valid. Is there a spending limit? Does a revised amount cancel earlier approval? Can the requester approve their own request?
Write each rule in business language. Where possible, give concrete input and expected output. An amount of Rp8 million submitted to a manager with a Rp5 million limit should require a higher approver. Those figures illustrate a proposed rule; they are not a universal financial policy.
A worked set of criteria
For that approval story, an initial checklist might be:
- A manager can view requests assigned to their department, including the quoted amount and attachments
- A manager within the configured approval limit can approve a pending request, and the system records their identity and time
- The requester cannot approve their own request, even by calling the API directly
- Editing the supplier or amount returns the request to review and preserves the earlier decision in history
- Two simultaneous approval attempts produce one effective transition, with the second user seeing the current state
- A failed save does not display a success message or create a purchase order
These criteria define behavior without dictating a specific database or front-end framework. Developers can choose the implementation while testers retain an independent way to assess it.
Include boundaries and negative cases
Test values just below, exactly at and just above a limit. Include a missing attachment, a deactivated approver and a request already canceled. Check access for someone in another department. A feature that works only for a fully populated administrator account has not yet demonstrated the intended business behavior.
Performance criteria need a named workload and measurement method. "Loads quickly" is weak. "Shows the first page within the agreed target using the representative test dataset and office connection" becomes reviewable when the target, dataset size and measurement procedure are recorded.
Separate story criteria from release standards
Criteria for an individual story differ from requirements applied to every release. Security review, automated checks, accessibility expectations and operational documentation belong in shared release standards rather than being copied inconsistently into each story.
The Scrum Guide describes the Definition of Done as the common quality commitment for an increment. Teams using another delivery method can still establish a shared release checklist. Story-specific criteria then explain what this particular capability must achieve.
Agree on evidence before implementation
Name the person who will accept the result and the examples they will review. Some criteria need an automated test; others need a user demonstration or a restored backup. Keep screenshots and recordings proportionate, and avoid collecting unnecessary personal data as evidence.
When a new exception appears during testing, decide whether it clarifies the original rule or introduces new scope. Record that decision openly. Acceptance criteria work best as an agreed contract for observable behavior, with a process for revising the contract when evidence changes.
Primary references
Related reading
Our IT consulting team can help translate business rules into criteria you can verify.