Acceptance Criteria: How to Write Them (With Templates)

Acceptance criteria are the specific conditions a feature must meet to be considered complete and acceptable. They’re the “yes/no” checks that align product, design, engineering, and QA on what success looks like.

When teams skip acceptance criteria (or write them like a mini-spec), refinements drag, QA guesses, and “done” becomes a debate. This guide covers Gherkin, the DoD distinction, and a simple template you can reuse.

‍

Gherkin Acceptance Criteria that Developers Trust

If you’ve ever seen “Given / When / Then,” you’ve already met Gherkin. Gherkin is a structured language used in BDD to describe behavior in plain English, and it's great for acceptance criteria because it reads like a test and stays focused on outcomes.

Use Gherkin acceptance criteria when a story has multiple paths, permissions, or edge cases, or when QA and devs want “living documentation.” A checklist can be enough for tiny UI tweaks, but Gherkin shines when behavior matters more than screens. For a solid, practical definition, Atlassian’s guide about acceptance criteria is a helpful reference.

Here’s a lightweight given when then acceptance criteria example for “Reset password”:

• Given: I’m on the login screen
• When: I request a password reset with a registered email
• Then: I see a confirmation message and receive a reset email within 2 minutes
• Given: I request a reset with an unregistered email
• When: I submit the form
• Then: I see the same confirmation message (to avoid account enumeration)

Notice what’s missing: implementation details. You’re specifying what the system must do, not how it does it.

‍

Definition of Done vs. Acceptance Criteria in Scrum

Teams often mix these up, and it creates avoidable friction. The definition of done vs acceptance criteria boils down to scope:

• Acceptance criteria are story-specific. They describe this feature’s expected behavior and boundaries. If you want a quick dictionary-style explanation that stays grounded, Agile Academy’s entry is a nice complement.
• The Definition of Done (DoD) is team-wide. It’s the shared quality bar for all work (for example: code reviewed, automated tests passing, analytics events verified, and docs updated).

A practical rule: if it would apply to every story in the sprint, it belongs in DoD. If it only applies to this story (“reset email arrives within 2 minutes”), it belongs in acceptance criteria.

One real-world example from our delivery work: in a Rotageek scheduling engagement, we rewrote priority backlog tickets so they were refinement-ready, including clearer acceptance criteria. The immediate payoff was less time spent decoding requirements in ceremonies and more time estimating, planning, and shipping.

‍

An Acceptance Criteria Template You Can Reuse

A good acceptance criteria template should be fast to fill out and hard to misuse. This one works in Jira, Linear, or Notion:

• Outcome (1 sentence): What user problem is solved?
• Happy path (2–5 bullets): What must happen for the primary flow to pass?
• Edge cases (1–3 bullets): key exceptions (validation, permissions, limits).
• Non-functional constraints (optional): performance, accessibility, analytics, compliance.
• Notes/assumptions: anything QA needs to test confidently.

If the story is complex, replace “Happy path / Edge cases” with 2–4 concise Gherkin scenarios. Keep each scenario focused on one behavior, and avoid combining multiple assertions into a single Then. For another clear breakdown (plus examples), ProductPlan’s glossary entry is a handy bookmark.

If you want help making this consistent across your backlog, our product ownership service focuses on keeping stories crisp, testable, and ready for delivery.

‍

FAQs

‍

‍