Acceptance criteria examples: 2 formats and how to write them

Each card or user story gets its own acceptance criteria. They describe what the result must do, from the user's point of view, not how to build it. They're written before the work starts, agreed with the person who asked for it, and checked before the card counts as done.

They are not the same as a definition of done. Acceptance criteria belong to one card. The definition of done applies to every card, with checks like "reviewed" and "tested". A card is finished when it meets both.

A plain list of statements, each true or false. Quick to write and easy to check.

Example: password reset

Story: As a user who forgot my password, I want to reset it by email, so that I can get back into my account.

• The sign-in page has a "Forgot password?" link.
• Entering a registered email sends a reset link within a minute.
• Entering an unknown email shows the same message, so nobody can find out who has an account.
• The link works once and expires after 1 hour.
• The new password must be at least 8 characters.
• After a reset, other signed-in sessions are signed out.

Example: a CSV export

• The export includes every column visible on screen, in the same order.
• Dates use the format YYYY-MM-DD.
• An empty list exports a file with the header row only.
• Exports of up to 10,000 rows finish in under 10 seconds.

A scenario format from behaviour-driven development. Each scenario says the starting state, the action, and the expected result. It's longer, but it reads as a test, and some teams turn it into automated tests directly.

Example: a discount code

• Given a basket worth 50 and a valid 10% code, when the customer applies the code, then the total shows 45.
• Given an expired code, when the customer applies it, then the total is unchanged and the message says the code has expired.
• Given a code has already been applied, when the customer applies a second code, then the message says only 1 code can be used.

Example: an approval flow

• Given an expense over 500, when it's submitted, then it goes to the submitter's manager for approval.
• Given an expense under 500, when it's submitted, then it's approved automatically.

• Use a checklist for most work: content, design, simple features, internal changes. It's faster to write and to check.
• Use Given, When, Then where behaviour depends on the situation: rules, permissions, money, edge cases. The structure makes you think through each case.

Mixing them on one team is fine. Mixing them on one card usually isn't.

1. Write them before work starts. Criteria written afterwards describe what was built, not what was needed.
2. Agree them with the person who asked. They're the contract between the 2 of you.
3. Make each one testable. "Fast" can't be checked. "Loads in under 2 seconds" can.
4. Describe the result, not the build. "The customer can pay by credit card", not "add a Stripe form".
5. Cover the unhappy paths. Wrong input, empty lists, no permission, no connection.
6. Keep the list short. 3 to 7 criteria. If you need 15, the card is too big. Split it.

In craaft, acceptance criteria fit naturally as a checklist on the card:

• Add each criterion as a checklist item, so the card shows how many are met, like 3/5.
• Tick them off as they pass review, and only move the card to done when they're all ticked.
• Agree changes in the card's comments, so there's a record of what changed and why.
• An agent connected over MCP can draft criteria from a story and add them to the checklist for you to edit.