Acceptance criteria
Acceptance criteria are specific conditions that a feature or user story must satisfy to be considered complete. They define what "done" means for a particular piece of work, providing clear expectations for developers, testers, and stakeholders. Well-written acceptance criteria eliminate ambiguity about whether a feature meets requirements.
Why it matters
Without acceptance criteria, "done" is subjective. The developer thinks a feature is complete, but the product manager expected something different. The tester doesn't know what to test against. Stakeholders are surprised by what was delivered.
Acceptance criteria create shared understanding before work begins. When everyone agrees on what success looks like, development proceeds with confidence, testing has clear targets, and stakeholder reviews go smoothly.
They also scope the work. By defining what must be true for acceptance, criteria implicitly define what's not required. This prevents scope creep during development and keeps work focused.
What good criteria look like
Effective acceptance criteria share several characteristics:
Specific and measurable criteria can be verified. "The page should load quickly" is vague. "The page should load in under 2 seconds on a 3G connection" is testable.
Independent of implementation criteria describe what, not how. "Use Redis for caching" is an implementation detail. "Returning users see their dashboard in under 500ms" describes the outcome without constraining the solution.
Complete but minimal criteria cover what's necessary without over-specifying. Include what matters; omit what doesn't.
Written in business language criteria should be understandable by non-technical stakeholders. If only developers can understand the criteria, stakeholders can't meaningfully accept the work.
Common formats
Given-When-Then (from behavior-driven development) structures criteria as scenarios:
Example: Given a logged-in user with items in their cart, when they click "Checkout," then they are taken to the payment page with their cart items displayed.
Checklist format presents criteria as a simple list of conditions:
Rule-based format states constraints and rules:
Any format works as long as the criteria are clear and testable.
Writing acceptance criteria
Start by understanding the user story or feature. What problem does it solve? Who is it for? What outcomes matter?
Identify the happy path-what happens when everything works correctly. This is usually the core criterion.
Consider edge cases and error conditions. What happens when input is invalid? When the user lacks permission? When the system is unavailable?
Think about non-functional requirements. Are there performance expectations? Security considerations? Accessibility requirements?
Review with the team. Developers may spot technical considerations you missed. Testers may identify scenarios you hadn't considered. Discussion improves the criteria.
Criteria vs. definition of done
Acceptance criteria and definition of done are related but different:
Acceptance criteria are specific to one story or feature. They describe what this particular work must accomplish.
Definition of done applies to all work. It describes team-wide standards like "code reviewed," "tests passing," and "documentation updated."
Both must be satisfied for work to be complete. The criteria define what's built; the definition of done ensures how it's built meets quality standards.
Common problems
Too vague criteria like "the feature should work well" don't provide useful guidance. Push for specificity: work well for whom, under what conditions, measured how?
Too detailed criteria that specify every pixel and interaction constrain designers and developers unnecessarily. Focus on outcomes, not implementation.
Missing criteria leave important scenarios undefined. This often manifests as "that's not what I expected" conversations after development.
Unstable criteria that change during development cause rework and frustration. Finalize criteria before committing to work, and treat changes as scope additions.
No criteria at all is surprisingly common. Teams skip criteria because writing them takes time, then spend more time on rework and misaligned expectations.
Acceptance criteria in practice
Criteria should be written before development begins, ideally during backlog refinement. The conversation about criteria often reveals that the story isn't well understood, which is valuable to discover early.
During development, criteria guide implementation decisions. When developers face choices, they can ask which option better satisfies the criteria.
In testing, criteria become test cases. Testers verify each criterion, and passing all criteria indicates the story is ready for acceptance.
In acceptance, stakeholders review work against criteria. If criteria are met, the work is accepted. If not, specific gaps are identified.
Klero helps teams write better acceptance criteria by providing customer context. When you can see what users actually requested and why, criteria better reflect real needs rather than assumptions.
