Acceptance criteria have one job: describe what changes. Not what stays the same. Not what was already working before the sprint started.
In my previous role, I caught this mistake twice in a single story-writing session. The second time, I realised this was not a typo or a lapse in concentration. It was a misunderstanding of what acceptance criteria are actually for. And it is common enough to be worth writing down.
Acceptance criteria that document existing behaviour are regression tests. They belong in your QA suite, not your story. The story is about change. Write the criteria accordingly.
What was happening
The stories were part of an error-handling epic. We were adding structured, user-facing error messages to a payment flow that had previously surfaced raw system errors or, in some cases, silent failures. A meaningful piece of work, with a clear user need behind it.
The first draft of acceptance criteria included things like:
- Payment form loads correctly on page visit
- Successful transactions complete without errors
- Form validation works as expected
None of those were acceptance criteria for an error-handling story. They were descriptions of what the system already did before we touched it. The new behaviour, the thing the story was actually about, was buried in the fifth bullet point, after four criteria that described the status quo.
Why this happens
Writing AC that describes existing behaviour comes from a legitimate concern: we want to make sure we do not break anything. Regression is a real risk. The instinct to document what should keep working is understandable.
But that concern belongs in the test plan, not the story. Regression testing is about preserving existing behaviour. Acceptance criteria are about defining new behaviour. Conflating the two creates stories that are harder to estimate, harder to review in sprint, and harder to use as a meaningful record of what was actually built and why.
When a developer reads acceptance criteria, they should be able to answer one question clearly: what is this story asking me to change? If the answer requires hunting through a list of existing-state descriptions to find the one new thing, the criteria are not doing their job.
The test I now apply
When writing or reviewing acceptance criteria, I ask one question about each criterion: could this have been written before this story was raised?
If yes, if it describes something the system already does or something unrelated to the specific change, it does not belong in the story. Move it to your regression checklist. Or delete it entirely if it is already covered by existing tests.
What belongs in AC:
- The new behaviour the story introduces
- The edge cases specific to that new behaviour
- The error states that are in scope for this story
- The definition of done for the change itself
What does not:
- Descriptions of existing features continuing to work as they already do
- General system health statements
- Anything a tester would verify regardless of whether this story shipped
Why it matters beyond one sprint
This is not just about writing cleaner stories. It is about the integrity of your backlog as a record over time.
When stories close, their acceptance criteria become a form of lightweight documentation, a record of intentional decisions. If your closed stories are full of “form loads correctly” and “validation works as expected,” you have lost the signal. You cannot tell from the history what actually changed, what decisions were made, or what the team was solving for.
Stories with precise AC, criteria that describe exactly what changed and why, create a backlog you can learn from. That matters for future planning, for onboarding team members who were not in the room, and for postmortems where you need to reconstruct what was supposed to happen and when.
Jeff Patton’s work on user story collaboration makes the point that stories are not requirements documents. They are placeholders for a conversation. But the acceptance criteria are where that conversation gets committed to. They are the record of what “done” meant for this specific change, at this specific moment. That record is only useful if it is precise.
The correction I made twice
After catching this in the same session twice, I added one step to our story-writing process: before finalising AC, I read the list back and ask whether any of these criteria would be true without this story shipping. If the answer is yes for more than one item, the criteria need reworking.
It takes about 90 seconds. It consistently produces sharper stories, cleaner sprint reviews, and a clearer record of what the team actually built.
Acceptance criteria are not a safety net for things that should not break. They are a precise description of what is changing. Those are different documents, and the difference is worth protecting.
TL;DR: Before accepting a criterion into a story, ask whether it could have been written before the story was raised. If yes, it is describing existing behaviour, and it belongs in your regression suite, not your backlog. Acceptance criteria describe change. That is their only job.
Written by Delphine Ragazzi, Product Owner with 20 years in digital product, analytics, and CRO.
