The Story Everyone Approved and Nobody Could Test
During Sprint Planning, a Scrum Team pulled in a story that read, simply, 'Users can reset their password.' Everyone nodded. The Product Owner was happy, the Developers estimated it, and it went into the Sprint Backlog. Three days later it was 'done' — and immediately disputed. The Product Owner expected an email link with an expiry; the Developers had built a security-question flow. Both were defensible readings of one vague sentence. This is an anonymized but very ordinary situation, and the root cause is almost always the same: the item had no acceptance criteria.
What acceptance criteria actually are
Acceptance criteria are the specific, testable conditions a Product Backlog item must satisfy to be considered complete by the Product Owner. They are not the Definition of Done — the Scrum Guide describes the Definition of Done as the shared quality standard applied to every Increment (tests pass, code reviewed, deployable). Acceptance criteria are particular to one item: they describe what this story, specifically, must do. A team needs both. Done is the bar every item clears; acceptance criteria are how you know this item did the right thing.
Rewriting the password story with criteria changes everything:
Given a registered user requests a reset, when they submit their email, then a reset link is sent to that address.
The reset link expires 30 minutes after it is issued.
An expired or already-used link shows a clear message and offers to resend.
After a successful reset, the user's previous password no longer works.
Now there is nothing to argue about at the end of the Sprint. The conversation that would have been a tense dispute over a finished build happened instead during refinement, cheaply, before a line of code was written.
Habits that keep criteria useful
Write them before the item is sprint-ready. Acceptance criteria belong to Product Backlog refinement, not to the demo. A story without them is not ready to be planned.
Make every criterion testable. If you cannot imagine the check that proves it true or false, it is a wish, not a criterion. 'Fast' is a wish; 'responds within two seconds' is a criterion.
Keep them about outcomes, not implementation. State what the user must be able to do, and leave the Developers room to decide how. Criteria constrain the result, not the design.
Keep the set small. Three to six sharp conditions beat fifteen vague ones. If a story needs a dozen criteria, it is probably two stories.
Why this matters more on a distributed team
When everyone shared a room, a half-defined story could survive on quick clarifying questions across the desk. With teams working remotely, that informal repair channel is weaker and slower. Written, testable acceptance criteria carry the shared understanding that hallway conversations used to. They are not bureaucracy — they are the cheapest insurance a Scrum Team has against building the wrong thing well.
If your teams keep finishing work that misses the intent, XNM's program & project delivery advisory can help you tighten how you define and accept work.