AgileToolHub
TemplatesUpdated August 4, 2026

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.

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

FormatBest forExample use
Given/When/ThenUser flows, behavior, BDD, QA automationLogin, checkout, password reset, onboarding
ChecklistSimple validation and Jira ticket clarityForm fields, copy changes, admin settings
Rule-basedPolicy-heavy or business-logic-heavy storiesPricing, permissions, tax, eligibility
BothImportant work with user behavior and QA coveragePayments, 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.

Try the Acceptance Criteria Generator

Generate testable Given/When/Then and checklist criteria in seconds.