Lesson 24: Acceptance Criteria

Lesson 23 ended with the INVEST criteria, and one letter in particular deserves a lesson of its own: Testable. A user story can pass every other INVEST check — independent, negotiable, valuable, estimable, small — and still leave open a question that causes real damage during a project: how does anyone actually know when it's done? Without an explicit answer, "done" quietly becomes whatever the engineer who built it believes is done, which may or may not match what the PM who wrote the story had in mind, which may or may not match what QA expects to verify, which may or may not match what the actual user experiences.

Acceptance criteria are the specific, testable conditions that define when a user story is genuinely complete — a checklist, written before implementation begins, that removes ambiguity about what "done" means and gives everyone involved (engineering, QA, design, and the PM) a shared, verifiable standard to build and test against. This lesson treats acceptance criteria not as bureaucratic overhead added on top of a user story, but as the mechanism that actually makes a story testable in more than name — closing the loop that Lesson 23 opened but didn't fully resolve.

Learning Objectives

1
Define acceptance criteria and distinguish them from a user story's "so that" clause and from a full PRD's functional requirements.
2
Apply the Given/When/Then (Gherkin) format for writing structured, testable acceptance criteria.
3
Distinguish acceptance criteria covering the happy path from those covering edge cases and negative scenarios, and explain why both are necessary.
4
Identify the "acceptance criteria written after the fact" failure pattern and explain why criteria written post-implementation lose their primary value.
5
Apply a structured method for writing acceptance criteria that are specific and testable without over-specifying implementation details, extending Lesson 22's Precision Dial.

Lesson 17 (Problem Statements) and Lesson 23 (User Stories). This lesson assumes you can write a well-formed user story satisfying INVEST — acceptance criteria are the mechanism that operationalizes the "Testable" criterion specifically, turning a story's stated capability into a concrete, verifiable definition of done.

The Core Definition and Its Place Relative to Other Artifacts

Acceptance criteria are the specific, testable conditions a user story must satisfy to be considered complete. It's useful to place this artifact precisely relative to its neighbors, since confusion between them is common:

A user story's "so that" clause (Lesson 23) states the underlying value or benefit — it explains why the capability matters, but doesn't specify exactly what conditions must hold for the capability to be considered correctly built.
Acceptance criteria specify the exact, verifiable conditions that must be true for the story to be considered done — a concrete checklist derived from, and consistent with, the story's stated benefit.
A PRD's functional requirements (Lesson 22) typically operate at a broader, feature-level scope, while acceptance criteria operate at the level of an individual, already-scoped user story.

Acceptance criteria written well should be traceable back to the story's "so that" clause: every criterion should plausibly serve the stated benefit, and any criterion that doesn't connect to that benefit is a candidate for Lesson 22's over-specification warning, now recurring at a more granular level.

The Given/When/Then (Gherkin) Format

A widely used, structured format for writing acceptance criteria is Given/When/Then (sometimes called Gherkin syntax, from its origin in behavior-driven development practice):

Given [a specific starting context or precondition], When [a specific action occurs], Then [a specific, observable outcome should result].

For example, for a story "As a user, I want to reset my password, so that I can regain access to my account if I forget it":

Given a user has requested a password reset and received a reset link, When they click the link and submit a new password meeting the minimum complexity requirements, Then their password should be updated and they should be able to log in with the new password.

This format is valuable specifically because it forces explicitness about context (the "Given"), the specific triggering action (the "When"), and a specific, observable result (the "Then") — removing the ambiguity that a vaguer statement like "password reset should work correctly" would leave wide open to inconsistent interpretation, directly echoing Lesson 22's under-specification warning.

Happy Path vs. Edge Cases and Negative Scenarios

Directly extending Lesson 15's "happy path only" warning to the level of acceptance criteria, a genuinely complete set of criteria must cover more than just the smoothest, most successful scenario. A well-rounded set of acceptance criteria for a given story should include:

The happy path: the primary, most common scenario in which everything goes as intended.
Edge cases: less common but plausible scenarios at the boundaries of expected behavior — an unusually long input, a boundary value, a rare but valid combination of conditions.
Negative scenarios: cases where something goes wrong or a precondition isn't met — invalid input, an expired session, insufficient permissions — and what the system should do in response.

A story whose acceptance criteria only cover the happy path is vulnerable to precisely the same blind spot Lesson 15 warned about for journey maps: real users, in aggregate, will encounter edge cases and error conditions with some regularity, and a story that hasn't specified expected behavior for these scenarios leaves engineering and QA to guess — usually inconsistently — what should happen, discovering the gaps only when a real user hits one in production.

The "Acceptance Criteria Written After the Fact" Failure Pattern

A specific, common failure — closely related to Lesson 8's discovery theater and Lesson 21's MVP theater patterns — is writing acceptance criteria only after a story has already been implemented, rather than before implementation begins. This inverts the entire purpose of the artifact: acceptance criteria's primary value is in forcing explicit, shared clarity about what "done" means before work starts, so that ambiguity is resolved through discussion rather than discovered through divergent interpretation during or after implementation.

When criteria are written retroactively, they tend to simply describe whatever was actually built, rather than genuinely testing whether the built solution correctly satisfies the story's intended benefit — a practice that provides the appearance of rigor (a checklist exists) without its substance (the checklist was never actually capable of catching a mismatch between intention and implementation, since it was written to match the implementation after the fact). This is functionally identical to Lesson 8's discovery theater concept: a test that could not, even in principle, have produced a disconfirming result is not really testing anything.

Common Mistakes to Avoid

Writing acceptance criteria that only cover the happy path

This leaves edge cases and negative scenarios unspecified, echoing Lesson 15's "happy path only" warning at the level of individual story verification, and leads to inconsistent, discovered-too-late handling of real, plausible scenarios.

Writing vague criteria that don't specify a concrete, observable outcome

"Password reset should work" is not an acceptance criterion in the useful sense this lesson intends — it fails to specify the given context, the triggering action, and the specific expected result with enough precision to be genuinely testable.

Over-specifying implementation details within acceptance criteria

Just as Lesson 22 warned against over-specification in a PRD, acceptance criteria should specify observable behavior and outcomes, not dictate a specific technical implementation approach — the "Then" clause should describe what should be true, not how the system should internally achieve it.

Writing acceptance criteria after implementation is already complete

This inverts the artifact's purpose, providing the appearance of a testable definition of done without the substance of having actually forced clarity before work began, echoing Lesson 8's discovery theater concept.

Treating acceptance criteria as replacing, rather than complementing, the story's "so that" clause

Acceptance criteria specify the conditions for done, but the underlying benefit stated in "so that" remains important context for evaluating whether the criteria themselves are actually well-chosen and complete.

Mental Model

The Acceptance Criteria Coverage Map

This lesson's mental model is the Acceptance Criteria Coverage Map — a simple discipline for checking that a story's criteria genuinely cover the happy path, edge cases, and negative scenarios, rather than only the most obvious scenario.

Before considering a story's acceptance criteria finished, explicitly check all three boxes: has the happy path been specified, has at least one meaningful edge case been considered, and has at least one negative or error scenario been addressed? A criteria set that only fills the first box has done only a third of the necessary work.

Quick Reflection Checkpoint

Key Takeaway: How will you apply "The Acceptance Criteria Coverage Map" when evaluating trade-offs in your product decisions?

Acceptance Criteria