Acceptance criteria describe the observable conditions a particular piece of work must satisfy. They help a team share an understanding of expected behavior and decide whether the result meets the need.
When ordering a custom shelf, agreeing on what it must hold and where it must fit makes the result easier to evaluate than asking for a nice shelf.
Describe behavior people can check
Write criteria in concrete terms: what triggers the behavior, what the system does, and what result is visible. Avoid vague words such as fast, intuitive, or correct without defining the relevant condition. Use examples when they make an important rule easier to understand.
Cover meaningful alternatives
Include important error states, permission boundaries, empty data, and recovery behavior alongside the successful path. Focus on conditions that affect the need or create material risk. A long list of trivial checks can hide the few rules that are essential to acceptance.
Agree before implementation
Discuss criteria with the people designing, building, and reviewing the work. Questions often expose missing decisions or contradictory expectations. Update the criteria when a decision changes and keep a record of why, so acceptance does not become a surprise at the end.
Example: saving a lesson
Criteria might state that an authenticated learner can save a lesson, see the saved state immediately, and find it after reload. If the request fails, the prior state returns with clear feedback. Those conditions describe an outcome that can be checked through the interface and stored data.
Frequently asked questions
Key takeaways
- Write observable conditions for a specific change.
- Include important failure and permission cases.
- Agree on criteria early and revise them deliberately.
- Use criteria to support design, implementation, and review.