Acceptance Criteria on a User Story: The Mistakes Teams Make Most Often

Acceptance criteria define the conditions under which a Product Backlog item is considered done by the Product Owner. They are the contract between the Product Owner and the Development Team for a specific item: if the criteria are met, the item is accepted; if they are not, it is not. Getting them right is one of the highest-leverage activities a Product Owner and Development Team can do before a Sprint begins.

Most teams know this in principle. In practice, acceptance criteria problems are endemic. The following describes the most common mistakes -- and what good acceptance criteria look like.

The Mistakes

1. Mistake 1: Too vague to be testable. "Works correctly" is not acceptance criteria. "The user receives a confirmation email within 60 seconds of submitting the form" is. Acceptance criteria must be specific enough that two people -- the developer who built the feature and the tester who tests it -- would make the same binary judgment about whether the criterion is met. If there is room for interpretation, the criterion is too vague.

2. Mistake 2: Written after development starts. When acceptance criteria are written after development has started -- or after the feature is complete -- they describe what was built rather than what was needed. This is a common pattern in teams where the Product Owner is too busy or the Sprint starts before criteria are defined. Fix: acceptance criteria should be reviewed and agreed by the Development Team before Sprint Planning ends. They are an input to Sprint Planning, not an output.

3. Mistake 3: Testable but not from the user perspective. Acceptance criteria can be technically testable but framed entirely from the system perspective rather than the user perspective. "The API returns a 200 status code" is testable; it is also useless as acceptance criteria unless the API response is the value the user receives. Frame criteria in terms of what the user can observe or accomplish.

4. Mistake 4: Missing edge cases and error states. Happy path acceptance criteria describe what happens when everything works. Most defects and rework occur in edge cases: what happens when the network is slow, when a field is empty, when a user submits duplicate data, when a session times out. A Product Backlog item without acceptance criteria for at least the most common error states is not ready for development.

5. Mistake 5: Not reviewed by the Development Team before the Sprint starts. Acceptance criteria that the Development Team has not read before Sprint Planning ends are acceptance criteria that will generate surprises during the Sprint. The Development Team should review each criterion, confirm it is testable, flag any ambiguities, and agree on the implementation approach for any non-obvious cases. This review is part of Backlog Refinement, not an optional extra.

XNM supports public-sector and capital-project organisations in building effective Scrum practices, including acceptance criteria definition and Product Backlog Refinement. Reach out to XNM's program & project delivery advisory team for support with your agile delivery.