What are acceptance criteria? Definition and examples

Acceptance criteria are the specific conditions a task must meet to be considered complete. They turn "make it work" into a checklist anyone can verify.

Key takeaways

• Criteria describe outcomes, not implementation steps.
• Each one should be testable: someone can say yes or no.
• They belong on the task so the doer and the reviewer read the same list.
• Clear criteria help humans and AI agents finish the right thing.

What good criteria look like

A useful criterion is short, observable and unambiguous.

Weak: "Password reset works well."

Better:

• A user who requests a reset receives an email within one minute.
• The link expires after 30 minutes.
• Using the link twice shows an error on the second use.
• The old password stops working after a successful reset.

The second list can be checked without debate.

A simple template

Write each criterion in the form when / then:

• When the user submits an empty form, then an inline error explains what is missing.
• When the API receives an unknown field, then it returns a 422 with the field name.

For non-functional needs, name the measure: "The list endpoint responds in under 300 ms for 1,000 rows."

Acceptance criteria versus definition of done

The definition of done is a team-wide standard: code reviewed, tests passing, docs updated. Acceptance criteria are unique to the task. Both must be true before you close it.

Common mistakes

• Describing how to build it instead of what must be true.
• Words like "fast", "easy" or "clean" with no measure.
• Hiding criteria in a comment thread instead of on the task.
• Writing them after the work is done.

Why they matter more with agents

A coding agent will do exactly what it thinks the task means. Explicit criteria narrow that gap. They also give a reviewer a fast way to check the result, since each item is either met or not.

In Osco, tasks have a checklist of acceptance criteria, and a task cannot be marked done until every item is checked. That keeps "done" honest.

Conclusion

Write acceptance criteria before work starts, keep them observable and put them on the task. The few minutes they take save rework and arguments about whether something is finished.