Acceptance Criteria Template for Jira: Copy, Examples & Checklist
Copy a free Jira-ready acceptance criteria template with Given/When/Then, checklist format, examples, QA review questions, and common mistakes.
Quick copy
One-click copy for your issue tracker format.
Quick links
Use this free acceptance criteria template when a Jira ticket needs clearer test conditions before sprint planning, development, or QA handoff.
Good acceptance criteria answer one simple question: what must be true before this story is accepted?
If you want a first draft from rough notes, use the Acceptance Criteria Generator. If you need the full story structure around the criteria, start with the User Story Template.
Copy-Paste Acceptance Criteria Template for Jira
Paste this block into your Jira issue description or acceptance criteria field, then replace the placeholders.
## Acceptance Criteria
### Behavior
Given [specific context or precondition],
When [user action or system event],
Then [expected result or visible outcome].
Given [error or edge-case condition],
When [user action or system event],
Then [safe, clear, and testable outcome].
### Checklist
- [ ] The happy path is covered
- [ ] Error states are covered
- [ ] Empty states or edge cases are covered
- [ ] Permission, role, or access rules are clear
- [ ] Data validation rules are clear
- [ ] Performance, security, or compliance constraints are explicit
- [ ] Analytics, notifications, or audit events are listed if needed
- [ ] The expected result can be tested by QA
### Open Questions
- [ ] [Question blocking clear acceptance]
- [ ] [Business rule or edge case that needs Product Owner confirmation]
Quick Format Selector
| Format | Best for | Example use |
|---|---|---|
| Given/When/Then | User flows, behavior, BDD, QA automation | Login, checkout, password reset, onboarding |
| Checklist | Simple validation and Jira ticket clarity | Form fields, copy changes, admin settings |
| Rule-based | Policy-heavy or business-logic-heavy stories | Pricing, permissions, tax, eligibility |
| Both | Important work with user behavior and QA coverage | Payments, account changes, security-sensitive flows |
Given/When/Then Acceptance Criteria Template
Use Given/When/Then when the story has a clear context, action, and expected outcome.
Given [precondition],
When [action],
Then [expected outcome].
Given [alternate condition],
When [action],
Then [expected outcome].
Given/When/Then example
Given a registered user is on the password reset page,
When they enter a valid account email and submit the form,
Then a password reset email is sent within 2 minutes.
Given the reset link is expired,
When the user opens the link,
Then they see an error message and can request a new link.
Checklist Acceptance Criteria Template
Use checklist format when the team needs quick, scannable acceptance conditions.
- [ ] User can complete the main action with valid data
- [ ] User sees a helpful validation message for invalid data
- [ ] Empty state appears when no results are available
- [ ] User without permission cannot access the feature
- [ ] The outcome is logged, measured, or communicated if required
Rule-Based Acceptance Criteria Template
Use this when the story depends on policy, pricing, eligibility, roles, or workflow rules.
## Business Rules
- Rule 1: [Describe the rule]
- Rule 2: [Describe the exception]
- Rule 3: [Describe the fallback]
## Acceptance Criteria
- [ ] Rule 1 is applied consistently
- [ ] Rule 2 exception is handled
- [ ] Invalid or unsupported cases show a clear message
- [ ] QA can test each rule independently
Filled Example: Password Reset Feature
## Acceptance Criteria
Given a registered user is on the password reset page,
When they enter a valid account email and click "Send reset link",
Then they receive a reset email within 2 minutes.
Given the reset link has expired after 24 hours,
When the user opens the link,
Then they see "This link has expired. Request a new one."
Given the user enters an email that is not registered,
When they submit the reset request,
Then they see "If this email is registered, you will receive a link shortly."
Checklist:
- [ ] Reset links expire after 24 hours
- [ ] Each reset link can only be used once
- [ ] Requesting a new link invalidates older links
- [ ] The message does not reveal whether an email exists
- [ ] Password reset events are logged for security review
Filled Example: Checkout Discount Code
## Acceptance Criteria
Given a shopper has eligible items in the cart,
When they apply a valid discount code,
Then the order total updates with the discount amount.
Given a shopper enters an expired discount code,
When they apply the code,
Then they see a clear message that the code has expired.
Given a discount code cannot be combined with another offer,
When the shopper applies the code,
Then the system explains which offer is active and why.
Checklist:
- [ ] Discount cannot reduce the total below allowed minimums
- [ ] Tax and shipping calculations still use the correct rules
- [ ] Discount amount appears in the order summary
- [ ] Invalid codes do not change the order total
For more domain examples, see Acceptance Criteria Examples for Checkout and Acceptance Criteria Examples for API.
Acceptance Criteria Review Checklist
Before a story enters sprint planning, check that the criteria are:
- Testable - QA can prove whether each item passes or fails
- Specific - the expected outcome is concrete
- Complete - happy path, edge cases, and error states are covered
- User-focused - criteria describe behavior and outcomes, not internal implementation
- Agreed - Product, Engineering, and QA understand the same definition of accepted
- Small enough - the number of criteria does not signal an oversized story
Common Acceptance Criteria Mistakes
Avoid these patterns:
- Writing vague criteria such as "the page should load fast"
- Writing implementation tasks instead of outcomes
- Forgetting empty states, errors, permissions, or edge cases
- Adding criteria after development has already started
- Mixing several unrelated features into one story
- Using too many criteria instead of splitting the story
If the ticket is still unclear, use How to Write Acceptance Criteria or generate a first draft with the Acceptance Criteria Generator.
FAQ
What is an acceptance criteria template?
An acceptance criteria template is a reusable structure for writing the conditions a user story must meet before the team can call it done.
Can I paste this acceptance criteria template into Jira?
Yes. The template is written in Markdown-style sections that are easy to paste into Jira issue descriptions, acceptance criteria fields, or comments.
Should acceptance criteria use Given/When/Then?
Use Given/When/Then when the story has clear behavior, preconditions, and expected outcomes. For simpler work, a checklist can be faster and easier to review.
How many acceptance criteria should a story have?
Most user stories need 3 to 7 acceptance criteria. If the list is much longer, the story may be too large or the scope may need to be split.
Who writes acceptance criteria?
The Product Owner usually drafts them, then developers and QA refine them during backlog refinement or sprint planning.
What is the difference between acceptance criteria and Definition of Done?
Acceptance criteria are specific to one story. Definition of Done is a team-wide quality checklist that applies to every completed item.
Related Resources
Try the Acceptance Criteria Generator
Generate testable Given/When/Then and checklist criteria in seconds.