How do you write acceptance criteria that actually prevent rework?

The ticket said the export should "work correctly". It shipped, it exported something, and the sprint review opened with the sentence every BA dreads: "that is not what I meant."

"Done" is a definition, not a feeling, and acceptance criteria are where the definition lives.

The format

• Given the starting state, concrete: logged in, cart with 2 items, on the export page.
• When exactly one action by one actor: clicks Export as CSV.
• Then an observable, testable outcome: a CSV with all visible rows downloads within 10 seconds.
• And chains sparingly. Five Ands means it is two criteria wearing one ID.

Before and after

The pattern in every fix: adjectives replaced by numbers, and outcomes something a test can check.

The review checklist

Run every criterion through five words: testable (QA could automate it from the text alone), observable, singular, edge-aware, solution-free (it says what happens, never which shade of blue the button is).

And learn the smells: user-friendly (friendly to whom, measured how?), fast and robust (adjectives are opinions), etc. (the missing cases are where the bugs live), as expected (expected by whom is the entire dispute).

The three cases that pay the rent

The happy path is one criterion. Production incidents come from the other three:

• the empty case — zero rows, no data yet, a brand-new account
• the error case — API down, timeout, invalid input
• the permission case — wrong role, expired session, a shared link

A story with four criteria covering these is cheaper than the incident retro that writes them afterwards.

Write them before, or not at all

Criteria added at review time describe the demo, not the need, which is how every ticket passes while users keep complaining. Agree them before the first line of code with whoever will accept the work. If QA cannot write the test from the criterion alone, the criterion is not done.

The takeaway

Given/When/Then, numbers instead of adjectives, the three unhappy cases, agreed before coding. The print-ready PDF above is the format, the examples and the checklist on one page.