How to write acceptance criteria that settle arguments instead of starting them

Why does work keep coming back as "not what I meant" when the ticket had acceptance criteria on it? Because most acceptance criteria describe the feature instead of settling the decisions someone will have to make while building it. A criterion that reads "the export contains the right data" is not a criterion. It is the argument, restated. Good acceptance criteria are the disagreements you resolved in advance, written down as conditions that are plainly true or false.

That is the whole shift. You are not documenting a feature. You are closing doors.

The one test each line has to pass

Read a criterion and ask: could two reasonable developers build different things and both honestly say they satisfied this line? If yes, you have written a wish. The line survives only if it rules something out.

This is why so many criteria lists feel thorough and change nothing. "Errors are handled gracefully" rules out nothing. "Submitting the form twice within five seconds creates one record, not two" rules out the exact bug that would otherwise be discovered in the demo. Same effort to write. Completely different value.

A real story, and the criteria that would have saved a week

Take a story a support tool might actually carry:

As a support agent, I want to export the current ticket list to a spreadsheet, so that I can send a customer a summary of their open issues.

Here is the version that gets written when someone is tidying the backlog in a hurry:

• User can export the ticket list.
• The export contains the right data.
• The export works on mobile.
• Errors are handled gracefully.

Every one of those is satisfiable by almost any implementation, including the wrong one. The developer ships something reasonable, the product owner opens it, and there begins the loop.

Now the version that settles things:

• The export includes only the tickets matching the filters and search currently applied on screen, in the order shown, not the full ticket table.
• Columns are ticket ID, subject, status, assignee, created date, last updated. No other columns.
• Dates are rendered in the viewing agent's timezone, and the timezone is named in the column header.
• An agent's export contains only tickets that agent can already see in the app. A restricted agent gets none of another team's tickets.
• Exporting when no tickets match produces a file with a header row and no data rows. Not an error, not a zero-byte file.
• The file is named tickets-YYYY-MM-DD.csv, using the agent's local date.

Six lines, and each one names a decision that would otherwise be guessed. The third one is not hypothetical. Dates exported in UTC while the agent and the customer both sat in Sydney is exactly the kind of thing that gets a finished feature sent back, and it costs one sentence to prevent. "Created date" was never the ambiguous part. The timezone was.

Notice what is missing, too. Nothing in that list says "the code is reviewed" or "tests pass". That is a different agreement entirely, and if it has crept into your criteria, they will keep growing until nobody reads them.

When does Given/When/Then actually earn its keep?

Given/When/Then comes from Gherkin, the language Cucumber reads, and Gherkin was designed so a scenario could be specification, documentation and an executable test at the same time. That origin tells you when the format pays: when the starting state and the sequence of events are the thing in dispute, and when somebody is genuinely going to automate the scenario.

Truncation on that export story is a good candidate, because the interesting part is the state you begin in:

Given a filter matching 6,000 tickets, when the agent exports, then the file contains the first 5,000 rows and a message states that the export was truncated at 5,000.

Compare that with the same ceremony applied to the filename:

Given the export has completed, when the agent looks at the downloaded file, then its name is tickets-YYYY-MM-DD.csv.

Twenty-three words to carry a fact that took nine. A flat rule wrapped in three clauses reads like process theatre, and teams start skimming criteria that read like process theatre. Which is how the one scenario that mattered gets skimmed along with them.

So the position I will defend: choose the format per criterion, not per story. A story with four checklist rules and one Given/When/Then scenario is not inconsistent, it is proportionate.

I did not always think that. I used to argue for one format per team on the grounds that consistency makes a backlog scannable. What changed my mind was noticing where the handbacks were coming from. Not one of them was caused by mixing formats. They were caused by lines with no decision in them, in either format. Gherkin makes a vague criterion look rigorous, which is arguably worse than a vague bullet, because at least the bullet does not flatter itself.

Acceptance criteria are not in the Scrum Guide

Worth knowing, because it explains why every article on this topic proposes a different template. Search the 2020 Scrum Guide and neither the word "acceptance" nor the word "criteria" appears anywhere in it. The Definition of Done, by contrast, is defined in the guide directly, as a formal description of the state of the Increment when it meets the required quality measures. Scrum.org publishes plenty about acceptance criteria, but as a complementary practice, not as part of the framework.

Practically, that means two things. There is no canon to appeal to in a format argument, so your team decides and the only test is whether it works. And the distinction between the two is worth keeping crisp: the Definition of Done applies identically to every story, acceptance criteria apply to one. We wrote about where each of those lines belongs separately, so it is enough to say here that if a criterion would be true of every story on your board, it does not belong in this story's criteria.

How many criteria is too many?

If you are past roughly seven lines, something else is usually going on. Either the story is two stories, or your Definition of Done has leaked into the ticket, or you are specifying implementation rather than acceptance. The truncation rule in the example above is honestly borderline; on a real backlog I would probably split it out and let the first version fail loudly on huge exports.

Length is not the goal. Coverage of the decisions is. Three criteria that each close a real door beat twelve that describe the feature back to itself.

Write them with the person who will build them

Acceptance criteria written alone at 11pm are a guess about what a developer will find ambiguous, and you are the worst possible judge of that, because you already know what you meant.

The cheapest fix costs about four minutes. Before a story enters a sprint, read the criteria out loud to the developer and whoever tests it, and ask one question: how would you check this? Watch for hesitation. Hesitation is where the handback lives. This is not a new meeting either, it is what backlog refinement is for, and it works best on stories that are already written clearly enough to argue about.

Where AI helps, and where it cannot

Scrumpy has an acceptance criteria generator built into the story editor, so it would be strange not to say plainly what it does and does not do.

It reads the story's title and description, returns a list of concrete, testable criteria covering the happy path and the edge cases the description implies, and follows a short house-style playbook your team writes once in team settings. It is instructed not to invent scope, and when a description is too thin to derive anything real it says the story needs more detail first rather than filling the space with plausible filler. The result arrives as a suggestion: accept it to replace what is there, or discard it and keep your own. It only runs when you press the button.

What it cannot do is the part this whole article is about. Nothing in "export the ticket list" tells a model whether the export respects the active filter, which timezone the dates use, or whether a restricted agent sees other teams' tickets. Those answers do not exist in the story, they exist in your head and in a decision someone has to take. So the honest description is that AI removes the blank page and the obvious omissions, and you still supply the judgement. A generated list you accepted without reading is the same vague ticket you had before, just longer.

It is included in the flat per-editor price with no separate AI bill, though not unlimited: there is a fair-use allowance of 300 AI actions a month per paid seat, pooled across your organisation, which is a lot of story writing but is a real ceiling rather than a marketing one. More on how that is built into the plan rather than sold back to you.

In Scrumpy itself, acceptance criteria are their own field on a story rather than a heading you remember to type inside the description, and a team that does not want the field can switch it off in settings. If your team keeps needing the same criteria, a story template can carry them pre-filled so the boring three lines are already there when you start.

The point is a quieter Friday

None of this is about tidier tickets. It is about the demo where nobody says "that is not what I meant", because every question that would have caused it was asked while the work was still cheap to change.

Try it on the next story you write, before you save it. Take each line and name the wrong thing a developer could build that would still satisfy it. Any line where you cannot name one is already doing its job. Any line where you can just told you exactly what to write instead, and it will take you thirty seconds.