Skip to content
Software Architecture Guide

Frequent Mistakes in Defining Acceptance Criteria

Explanation

Section titled “Explanation”

Acceptance criteria are details that help a product owner and team confirm that a story was completed correctly. Teams often repeat the same few mistakes when they write them.

Replacing the conversation. Criteria should clarify the discussion about a story, not stand in for it. If stakeholders, the product owner, and the team skip the talk and only write a list, details stay unclear. Insufficient discussion is a mistake.

Forgetting the user. A long list of criteria can hide the user’s goal. Keep that goal visible. Center the criteria on the user’s behavior and language, not on a technical view.

Too much technical detail. Criteria should say what must be true for the user or product. They should not list every implementation step. Technical detail in criteria is also a warning sign that the story itself is too technical. It pushes a solution before developers have looked at the problem.

Vague criteria. Good criteria make a story more precise and testable. Old-style criteria failed in two ways. They gave developers no boundaries. They also gave QA no guidance on how to test. The “T” in the INVEST checklist (see INVEST Criteria) means testable: a story must be verifiable in principle, even if no test exists yet.

Missing shared criteria. The Definition of Done is a shared set of criteria added to every story. A story is done only when its own criteria and the Definition of Done are both met.

Format help. Given-When-Then describes a scenario from the user’s perspective. It comes from Behavior-Driven Development (BDD). Keep a single trigger in the When clause. Mixing preconditions and triggers defeats the format.

Pichler calls acceptance criteria perhaps the most misunderstood part of user stories.

Example

Section titled “Example”

A team writes a story: “As a shopper, I want to reset my password, so that I can get back into my account.”

Weak criteria: “The system calls the mail service through a queue and stores a hash in table X.” This is technical and says nothing the shopper can see. It also gives QA no clear check.

Better criteria: “Given I forgot my password, when I request a reset, then I receive a reset link.” A second one: “Given I opened a valid link, when I enter a new password, then I can log in with it.” Each one is written from the shopper’s view and can be tested. The team still talks through edge cases, such as expired links, instead of relying on the list alone.

Trade-offs

Section titled “Trade-offs”

Short, user-focused criteria leave room for the team to choose a solution. They also depend on real conversation, which takes time. Very detailed criteria feel safe, but they can lock in a technical solution too early and bury the user’s goal.

Checks

Section titled “Checks”
  • Acceptance criteria are written in the user’s behavior and language, not as implementation steps.
  • Each criterion is precise enough that QA can tell how to test it.
  • The user’s goal stays visible next to the criteria.
  • Given-When-Then criteria have a single trigger in the When clause.
  • Stories are marked done only when their own criteria and the Definition of Done are met.
Section titled “Related”

Sources

Section titled “Sources”