5 Patterns of Vague Acceptance Criteria

Most Bugs Aren't Implementation Mistakes — They're Misread Specs

Break down the bugs found in production and surprisingly few are cases where "the code was simply wrong." Far more common is a mismatch between what the PM intended and what the engineer inferred from the acceptance criteria. Testing doesn't catch this, because tests assume the criteria are already correct — and inherit whatever ambiguity they contain.

Acceptance criteria are a spec's last line of defense. Get the wording wrong here, and no amount of care downstream erases the misinterpretation.

5 Patterns of Vague Criteria

1. No subject

Bad: "Users can delete it." Who — the owner, an admin? Good: "The report's author can delete their own report; the delete button is hidden for everyone else."

2. No boundary values

Bad: "Title is required." Max length and whitespace handling are left open. Good: "Title must be 1–100 characters; whitespace-only input is rejected."

3. No defined error behavior

Bad: "Users can upload an image." Failure handling is undefined, so every implementer guesses differently. Good: "On upload failure, show an error and preserve the form's input so the user can retry."

4. Missing non-functional requirements

Scale conditions — counts, speed, concurrency — are often left out. Good: "The list shows up to 50 items per page; beyond that, results paginate" — a concrete number, not a vague promise.

5. No definition of "done"

Bad: "Users can update the status." Which transitions are allowed, and where is that confirmed? Good: "Status moves Open → In Progress → Done only, never backward, shown as the card's column on the kanban board."

Fix It on the Spot with Given/When/Then

These patterns are hard to catch while writing. So once a criterion is drafted, try breaking it into Given/When/Then. If it won't decompose cleanly, it's almost always missing a subject or a boundary value.

• Given: the precondition (who, in what state)
• When: the action or trigger
• Then: the expected outcome — down to numbers, copy, and the destination screen

Try decomposing "Users can delete it" and you'll notice there's no Given to write — that gap is your signal. Simply asking in review, "Can this be broken into Given/When/Then?" catches many spec misreads before a single line of code is written.

Putting This Into Practice with Bugoon

Even with solid acceptance criteria upfront, bug reports after launch never drop to zero. What matters is spotting quickly whether an issue is "implemented against spec incorrectly" or "the spec itself was ambiguous." Bugoon lets reporters submit bugs via an embedded widget with a screenshot, annotations, and the exact steps taken, then link straight to a GitHub Issue — making it easy to compare the report against what actually happened.

Linking a report to its related acceptance criterion could make that triage even faster — a direction worth noting, though not something the product does today.