Acceptance criteria
Acceptance criteria are the conditions a piece of work must satisfy to be considered done, agreed between the requester and the team before the work starts. They turn a shared intention into a checkable list, so that completion becomes a determination two people can reach independently rather than an opinion to argue about.
The longer version
A user story describes intent, and intent alone does not settle arguments about whether something is finished. Acceptance criteria are the settlement: written in advance, agreed by whoever asked for the work and whoever will do it, and specific enough that two people reading them reach the same verdict.
Two formats dominate. A plain checklist of conditions is the more common and reads fastest. The Given/When/Then form, borrowed from behaviour-driven development, states a starting state, an action and an expected outcome, and is more precise where the behaviour depends on context. Neither is better in general; the checklist is easier to write and the structured form is easier to turn into a test.
Good criteria describe outcomes rather than implementations. Stating that a user who submits an empty form sees an error naming the missing field is checkable and leaves the how open. Stating that the form calls a particular validation function is neither, and it locks in a decision that belongs to whoever writes the code.
The other property that matters is being written before the work, not after. Criteria added at the end describe what was built, which is a summary rather than a standard, and they cannot do the job of catching a misunderstanding while it is still cheap.
Common questions
Who writes acceptance criteria?
Usually the product owner or whoever requested the work, refined with the team before the work starts. Writing them together is what surfaces the misunderstandings, since the act of making a condition checkable is what exposes that two people meant different things.
What is the difference between acceptance criteria and a definition of done?
Acceptance criteria are specific to one piece of work and say what that work must do, while the definition of done is the team's standing checklist applied to every piece of work, and a story has to pass both.
When should acceptance criteria be written?
Before the work starts, and usually at refinement, when the story is discussed by the people who will build it and the person who asked for it. Writing them then is what surfaces a misunderstanding while it costs a conversation rather than a rewrite. Criteria written after the work describe what was built, which makes them a summary, and a summary cannot fail anything.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.