Glossary

What are acceptance criteria?

Acceptance criteria define how you know one particular card is done. How they differ from the definition of done, and how to write them.

Acceptance criteria are the checkable conditions under which one particular piece of work counts as satisfied. They answer "how will we know this is right?" — before it is built, not after.

How they differ from the definition of done

The definition of done applies to every card equally: tested, reviewed, deployed. Acceptance criteria apply only to this card: "above €1,000 a confirmation step appears". Mixing the two produces either an endless done list or cards with no checkable goal.

How to write them

Observable, and without prescribing the solution. "Search is fast" is not one; "a result appears in under a second across 10,000 cards" is. The Given … when … then … form is common, but a plain list does the job just as well.

When they get written

During refinement, before estimating. This is exactly what estimation founders on otherwise: two people give different story points because they are picturing different work — and that only surfaces at the reveal in planning poker.

In Zuuna

As a checklist on the card, with a progress indicator. That puts them in the same place as the work rather than in a document beside it.

FAQ

How many acceptance criteria should a card have?

As many as it takes to make it unambiguous — usually two to five. If you reach ten, the card is probably too big.

Who writes them?

Usually the product owner together with the team. Written alone they end up either too vague or prescribing the solution.

Are acceptance criteria the same as test cases?

No, but they are the basis for them. A criterion says what must hold; a test case says how you check it.

Ready to make it simpler?

Boards, sprints, docs and time tracking in one place — GDPR-compliant, hosted in the EU.