Acceptance Criteria Template
A structured acceptance criteria template using Given/When/Then scenarios, business rules, edge cases, non-functional requirements, and a definition of done. Ready for Jira or Linear. Free to copy, download, and use. No signup required.
# Acceptance Criteria **Feature / Story:** [Feature Name] **Author:** [PM Name] **Date:** [Date] **Status:** Draft / Reviewed / Approved > **Tip:** Acceptance criteria describe observable behaviour the system must exhibit. They are the contract between PM and engineering. If it's not written here, it's not in scope. --- ## Feature Summary > [1–2 sentences: what this feature does and who it's for] **User type:** [Who triggers this flow] **Entry point:** [Where the user starts — e.g. "Settings page → Billing tab"] --- ## Scenario 1: [Happy Path — Main Success Case] > The most common, successful use of this feature. - **Given** [the user is in state X — e.g. "logged in, has a Pro plan, has at least one project"] - **When** [the user takes action Y — e.g. "clicks 'Export PDF'"] - **Then** [the system does Z — e.g. "a PDF is generated and downloaded within 5 seconds containing all active insights"] **Additional conditions:** - [Any other expected system behaviour in this scenario] - [What the user sees / hears / receives] --- ## Scenario 2: [Alternative Success Path] > A valid variation of the happy path. - **Given** [context] - **When** [action] - **Then** [outcome] --- ## Scenario 3: [Error / Failure State] > What happens when something goes wrong. - **Given** [the user is in a state where the action could fail — e.g. "file exceeds 50MB"] - **When** [they attempt the action] - **Then** [the system shows a clear error message: "[copy]" and does not proceed] **Error message copy:** "[Exact text the user sees]" --- ## Scenario 4: [Permission / Role Boundary] > What happens when a user without access tries this action. - **Given** [user is on the Free plan / is not an admin / is not logged in] - **When** [they attempt the action] - **Then** [they see a paywall / redirect to login / see a disabled state with tooltip "Upgrade to Pro"] --- ## Scenario 5: [Edge Case — add as many as needed] - **Given** [unusual but valid context] - **When** [action] - **Then** [expected outcome] --- ## Business Rules > Constraints the system must always enforce, regardless of scenario. - [ ] [Rule 1 — e.g. "A user may not export more than 10 PDFs per day on the Free plan"] - [ ] [Rule 2 — e.g. "Export always uses the most recently saved version of the document"] - [ ] [Rule 3] --- ## Non-Functional Requirements | Requirement | Target | |---|---| | Performance | [e.g. "Response within 3s for files under 10MB"] | | Accessibility | [e.g. "All interactive elements keyboard-navigable; error messages announced by screen reader"] | | Browser support | [e.g. "Chrome 110+, Safari 16+, Firefox 110+, Edge 110+"] | | Mobile | [e.g. "Responsive at 375px viewport; no horizontal scroll"] | | Security | [e.g. "Only the file owner may download; no public URL without auth token"] | --- ## Out of Scope > Be explicit — this prevents scope creep and "but I assumed..." conversations. - [Feature or behaviour that is NOT included in this ticket] - [Future enhancement that is intentionally deferred] --- ## Definition of Done - [ ] All scenarios above pass in staging - [ ] Acceptance criteria reviewed and signed off by PM before merge - [ ] Analytics event fires on [key action] with [expected properties] - [ ] No regressions in [related flow] - [ ] Help center updated if this is a user-visible change - [ ] Design matches approved Figma spec (link: [URL])
How to use this Acceptance Criteria template
Always write Scenario 3 — the failure state
Most PMs write the happy path and stop. Failure states are where the most debates happen during development. Write what the user sees when something goes wrong before engineering starts building.
Include the exact error message copy
Don't write 'show an error message' — write the exact copy. This forces you to think about tone and information density, and prevents engineers from shipping unhelpful messages like 'Error 500'.
Use the Business Rules section for invariants
Business rules are constraints that must always hold regardless of scenario — like rate limits, access controls, or data retention rules. Listing them separately prevents them from being accidentally omitted from one scenario.
Get engineering sign-off before sprint starts
Acceptance criteria that engineers haven't read before starting a sprint aren't acceptance criteria — they're surprises at code review. Walk through the scenarios together in refinement.
Want a Acceptance Criteria grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
How is acceptance criteria different from a user story?
A user story describes what the user wants and why ('As a PM, I want to export my PRD as a PDF so I can share it with stakeholders'). Acceptance criteria describe the specific conditions under which that story is considered complete. Every user story should have acceptance criteria; not every acceptance criteria set needs a full user story.
How many scenarios should I write?
At minimum: 1 happy path, 1 error state, and 1 permission boundary. For complex flows, 6–10 scenarios is normal. If you find yourself writing more than 12, the story is probably too large and should be split.
Should acceptance criteria be written in Given/When/Then format?
Given/When/Then (Gherkin-style) is the most common format because it forces you to specify context, trigger, and outcome separately — which prevents ambiguous criteria. It can also be used directly by QA for automated test cases. That said, for simple internal features, a checklist of conditions is fine.
Who owns acceptance criteria?
The PM writes the first draft; engineering validates it for completeness and technical feasibility; QA uses it as the test spec. All three should review before a ticket enters development. If engineering consistently discovers gaps during development, the criteria aren't being reviewed early enough.
Other free templates