Useful acceptance criteria describe the observable result, important business rules and relevant failure cases in language that a reviewer can verify. They clarify the boundary of a requirement without dictating the technical implementation, and they work best when the business owner, users, designer, developer and tester discuss them before work begins.
Put this guidance into practice
Explore our custom CRM and ERP development, software development, application launch, premium website development and business automation services. We scope the work around your existing tools, team and goals.
Start with the user outcome
Acceptance criteria are not a shorter version of a technical specification. Begin with the person who needs the capability, the task they are trying to complete and the business reason it matters. A criterion such as ‘add a customer status field’ says what to build but not what decision the field supports.
A stronger requirement might explain that a service manager needs to distinguish active, paused and closed customer accounts so that open work is not assigned to an unavailable account. The criteria can then describe what a user should see and what the system should prevent in each state.
GOV.UK guidance links user stories back to researched user needs and notes that stories commonly include acceptance criteria, complexity and dependencies. Keeping that connection visible helps a delivery team avoid completing a ticket that does not help anyone finish the real task.
- Who needs the capability?
- What are they trying to complete or decide?
- What business rule or risk makes it important?
- What evidence will show that the outcome works?
Describe behaviour that can be observed
Write each criterion so a reviewer can demonstrate whether it passed. ‘The dashboard should be easy to use’ is subjective. ‘A sales manager can filter open opportunities by owner and expected close month, then export the same filtered records’ is observable and testable.
Microsoft’s Azure Boards guidance recommends defining customer acceptance criteria before work begins and using them as the basis for acceptance tests. It also advises describing who the story is for, what the person wants to accomplish and why, while leaving the development approach to the team.
Use plain language that a business reviewer and technical team can interpret in the same way. Include sample values only when they clarify a rule; avoid turning every criterion into a long list of interface details that may change during design.
- Use an action, condition and expected result
- Name the record, role or workflow involved
- State the rule rather than the preferred code or component
- Make pass or fail visible to a reviewer
Cover the normal path and the important exceptions
The happy path is rarely enough for operational software. If an enquiry is assigned automatically, decide what happens when the region is missing, the matching owner is unavailable, the customer already exists or the integration times out.
Choose exceptions according to business impact rather than trying to list every imaginable edge case. Prioritise cases that could lose money, expose information, create duplicate work, block a customer or leave a record without an owner.
For each important failure, define the visible state, the responsible person and the recovery route. A generic error message may be acceptable for the user, but operations may also need a traceable event, monitored queue or safe retry that does not create duplicates.
- Missing or invalid information
- Duplicate and repeated submissions
- Unavailable owner or approval authority
- Integration failure and safe retry
- Cancelled, expired or partially completed work
Include permissions, data and security boundaries
A criterion that describes only successful access can miss the greater risk: access that should not be allowed. State which role can view, create, change, approve, export or delete a record, and what should happen when someone without that permission attempts the action.
OWASP’s Application Security Verification Standard includes functional security constraints in user stories, such as allowing a person to edit their own profile without viewing or editing another person’s profile. That style turns an abstract security concern into behaviour that can be tested during delivery.
Avoid placing real personal or commercially sensitive data in examples. Use fictional test records and define retention, audit and masking needs where they affect acceptance. Security requirements that apply across the whole product should also appear in the shared Definition of Done rather than being copied inconsistently into a few tickets.
- Role and scope of permitted access
- Denied behaviour and safe error response
- Audit event for important changes
- Export, retention and deletion boundaries
- Test data that contains no real customer information
Separate feature acceptance from the Definition of Done
Acceptance criteria explain what must be true for one requirement. The Definition of Done sets the quality bar that applies to every completed increment, such as review, automated checks, accessibility, security testing, documentation and deployment readiness.
The Scrum Guide describes the Definition of Done as the formal state in which an increment meets the product’s quality measures. Work that does not meet it is not part of the increment. Keeping the two concepts separate prevents teams from repeating universal quality checks in every story while still preserving requirement-specific behaviour.
Agree the shared quality standard at product level and link to it from the requirement. Add feature-specific performance, accessibility or security criteria when the normal standard is not enough—for example, a high-volume import, a keyboard-intensive workflow or an approval that changes financial records.
- Acceptance criteria: specific behaviour and business rules
- Definition of Done: shared product quality measures
- Release criteria: operational readiness for a particular launch
- Evidence: tests, review notes and a working demonstration
Review the criteria before estimating and again before approval
Acceptance criteria improve delivery when they support a conversation, not when they are handed to a team as a finished contract. Review them with the people who understand the workflow, design, data, engineering and testing. Resolve unclear language and record genuine unknowns for discovery.
Azure DevOps guidance treats requirements management as continuous work involving documentation, analysis, prioritisation, tracking and stakeholder agreement. Criteria can change when research reveals a better solution, but the owner, reason and effect on scope should remain visible.
During the review, demonstrate the real behaviour against the criteria, including at least one important exception and permission boundary. Record what passed, what remains and who accepted it. DigiStartup India uses this approach to scope and review custom CRM, ERP, portals and web applications around clear business workflows rather than vague feature lists.
- Discuss criteria before the estimate becomes a commitment
- Trace each criterion to a user need or business rule
- Demonstrate working behaviour with realistic fictional data
- Record acceptance, defects and agreed scope changes
- Keep unresolved ideas in the backlog rather than silently expanding the release
Further reading
Frequently asked questions
How many acceptance criteria should one requirement have?+
Use only enough to define the observable outcome, key rules and important exceptions. If the list becomes difficult to review, the requirement may contain several capabilities and should be split into smaller pieces that can be delivered and tested independently.
Should acceptance criteria describe the user interface?+
Only where a particular interaction, message or accessibility behaviour is essential to the outcome. Describe the rule and evidence first. Let design and engineering choose the implementation unless a legal, brand, device or integration constraint genuinely limits the solution.
Who should approve acceptance criteria?+
A named business or product owner should accept the outcome, with input from real users and the people responsible for design, engineering, testing, security, operations or compliance when relevant. The approver must have authority to make the scope decision.
Can acceptance criteria change during development?+
Yes, when new evidence or a discovered constraint changes the understanding of the requirement. Record the reason, owner, cost or timing effect and update the tests. Do not quietly change the criteria after work is demonstrated merely to make an incomplete feature appear finished.