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 simple checklist can be enough for tiny UI tweaks, but Gherkin shines when behavior matters more than screens—especially when you want to turn expectations into something that can drive acceptance testing.

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.

This approach maps neatly to a classic Agile idea: user stories get clearer through conversation, and then you lock in shared expectations via confirmation. Ron Jeffries’ 3 C’s (revisited) is a great reminder that acceptance criteria shouldn’t replace discussion, they should capture the outcome of it.

Also worth remembering: there are (at least) two practical ways teams add detail: by expanding the story description or by adding acceptance criteria that drive testing and alignment. Mountain Goat Software explains those two ways to add detail to user stories really clearly, and it’s a useful sanity check when you’re tempted to cram everything into a single ticket.

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

‍

‍