Acceptance criteria
Also called AC, conditions of satisfaction.
The testable conditions a feature must meet before the person who asked for it accepts it as done.
Last updated
What it is.
Acceptance criteria turn a request into a short list of checks anyone can run. Each one describes a result you can see, not how the code works: given this situation, when the user does this, then this happens.
They usually sit under a user story and are agreed before work starts. Together with the team's definition of done, they decide whether a piece of work can be closed.
Why it matters
Most arguments about whether a feature is finished are really arguments about what was asked for. Written criteria settle that up front. They also give testers a script, help engineers estimate, and make a fixed-price contract or milestone payment easy to sign off.
In a product build
Acceptance criteria are what a milestone is signed off against. OceanLab can bill product builds per milestone, so each milestone needs criteria both sides agreed before the work began.
Common mistakes.
- 01
Writing them after the feature is built, so they describe what was made instead of what was needed.
- 02
Leaving out the unhappy paths: empty states, errors, permissions and slow networks.
- 03
Describing the solution ("use a dropdown") instead of the outcome the user needs.
Related terms.
- User storyA short description of a feature from the point of view of the person who needs it, and why they need it.
- Definition of done (DoD)The shared checklist every piece of work must pass, such as tested, reviewed and deployed, before the team calls it finished.
- MilestoneA checkpoint in a project where an agreed piece of work is delivered, checked and, often, paid for.
- Change requestA written request to change the agreed scope of a project, with its effect on cost and timeline agreed before work starts.
Guides and pages
Browse the full glossary or read answers to common questions.
