Acceptance Criteria That Prevent 'Done' From Not Meaning Done
Acceptance Criteria That Prevent 'Done' From Not Meaning Done
TLDR: Well-written acceptance criteria eliminate ambiguity about what 'done' means, reducing rework cycles and keeping sprints on track.
Every project manager has experienced the frustrating moment when a developer marks a story as done, the product owner reviews it, and the response is "That is not what I meant." The story gets reopened. The sprint plan shifts. Trust erodes. This cycle repeats until someone finally writes acceptance criteria that leave no room for interpretation.
The Cost of Vague Acceptance Criteria
When acceptance criteria are missing or unclear, every person involved fills in the gaps with their own assumptions. The developer assumes the simplest implementation. The designer assumes pixel-perfect adherence to the mockup. The product owner assumes edge cases were handled. Nobody is wrong based on what they were given. Everybody is wrong based on what was needed.
The cost is not just rework time. It is the meeting to discuss what went wrong. It is the demoralized developer who thought they delivered. It is the sprint velocity hit when a story bounces back to in-progress. In LocalPM, when you move a story backward on the board, that should feel like a red flag, not a routine occurrence.
Anatomy of Strong Acceptance Criteria
Good acceptance criteria share four characteristics. They are specific, testable, independent, and written from the user's perspective.
Specific means no subjective language. Replace "the page should load quickly" with "the page should load in under two seconds on a 4G connection." Replace "the form should be user-friendly" with "the form should display inline validation errors within 200 milliseconds of the user leaving a field."
Testable means someone can verify the criterion with a yes or no answer. "The system handles errors gracefully" is not testable. "When the API returns a 500 error, the user sees an error message saying 'Something went wrong. Please try again.' and a retry button" is testable.
Independent means each criterion stands on its own. If criterion three only makes sense after reading criteria one and two, rewrite it to be self-contained.
User-perspective means writing from the viewpoint of someone interacting with the feature. "The database stores the record" is an implementation detail. "The user can see their saved preferences after logging out and back in" is a user-observable behavior.
The Given-When-Then Format
One of the most reliable formats for acceptance criteria is Given-When-Then. It forces you to define the starting state, the action, and the expected outcome.
- Given the user is on the dashboard and has three active projects
- When the user clicks the "New Project" button
- Then a modal appears with fields for project name, description, and start date, and the project name field is focused
This format works because it makes implicit context explicit. Everyone reading the criterion starts from the same understanding of the scenario. In LocalPM, you can add acceptance criteria directly in your story descriptions, making them visible to anyone who opens the story card.
Common Mistakes to Avoid
Writing acceptance criteria after development starts. If the developer has already begun coding, the criteria become a description of what was built rather than a specification of what should be built. Write criteria during backlog refinement, before sprint planning.
Including implementation details. "The feature should use a React modal component with a fade-in animation" mixes acceptance criteria with technical decisions. Describe what the user experiences, not how the code works. Let the development team choose the implementation approach.
Having too many criteria per story. If a single story has twelve acceptance criteria, it is probably too large. Consider splitting it into smaller stories. A good target is three to seven criteria per story.
Forgetting the unhappy path. Most teams write criteria for when everything goes right. The best teams also write criteria for what happens when the network fails, the input is invalid, or the user does something unexpected.
Building the Habit
Start your next backlog refinement session by reviewing existing stories and asking one question for each: "How will we know this is done?" If the answer is not written down in testable language, rewrite the acceptance criteria on the spot.
Over time, well-crafted acceptance criteria become second nature. Stories move from in-progress to done without bouncing back. Sprint commitments become more reliable. And the phrase "that is not what I meant" disappears from your retrospectives. For the full picture of effective story writing, read about story descriptions that give developers everything they need. And to make estimation more consistent alongside better criteria, see why story points matter.
Learn More
Ready to write acceptance criteria that eliminate rework? Check out the complete training series:
Watch the Project Management AI Playlist on YouTube
For more project management insights and resources, visit subthesis.com