Jira writing guide

Jira acceptance criteria examples for product and QA teams

A Jira ticket becomes easier to build and test when it states the expected behavior, validation rules, and visible outcomes. Use these examples as a starting point, then adapt the details to your product.

Where acceptance criteria belong in Jira

Add acceptance criteria to the issue description, below the user story or feature summary. Keep each scenario focused on one behavior. The goal is to make the ticket reviewable by a product manager, implementable by a developer, and testable by QA.

Use Given/When/Then when behavior matters

Given/When/Then makes the starting state, action, and expected result explicit. It is especially useful for Jira tickets that have permissions, validation, state changes, or multiple user paths.

Scenario: [short behavior name]
Given [starting state]
When [person or system action]
Then [observable result]
And [another relevant result]

Example 1: User login

Jira summary: Let registered users sign in with email and password.

Scenario: Sign in with valid credentials
Given a registered user is on the sign-in page
When they enter their valid email address and password
Then they are signed in and taken to their dashboard

Scenario: Reject an incorrect password
Given a registered user is on the sign-in page
When they enter a valid email address with an incorrect password
Then they see a clear sign-in error
And they remain signed out

Scenario: Validate missing required fields
Given a visitor is on the sign-in page
When they submit the form without an email address or password
Then each missing field shows a required-field message

Example 2: Checkout and payment

Jira summary: Allow a customer to complete checkout with a valid card.

Scenario: Complete checkout successfully
Given a customer has at least one item in their cart
And they have entered a valid delivery address
When they submit valid payment details
Then the order is created
And the customer sees an order confirmation with the order number

Scenario: Handle a declined payment
Given a customer is ready to pay for their cart
When the payment provider declines the payment
Then no order is created
And the customer sees a message that lets them try another payment method

Example 3: Role-based permissions

Jira summary: Restrict billing settings to workspace administrators.

Scenario: Let an administrator manage billing
Given a signed-in workspace administrator opens billing settings
When they change the billing email address and save
Then the new address is saved and shown on the billing settings page

Scenario: Block a non-administrator
Given a signed-in workspace member is not an administrator
When they try to open billing settings
Then they see an access-denied message
And no billing details are displayed

Example 4: File upload

Jira summary: Let users attach a supported document to a requirement.

Scenario: Upload a supported file
Given a signed-in user is creating a requirement
When they select a supported PDF smaller than 25 MB
Then the file name is shown before submission
And the requirement can be generated using the file content

Scenario: Reject an unsupported file
Given a signed-in user is creating a requirement
When they select an unsupported file type
Then the file is not uploaded
And the page explains which file formats are supported

Example 5: Product notification

Jira summary: Notify a user when a report is ready to download.

Scenario: Notify a user about a completed report
Given a user has requested a report
When the report finishes processing
Then the user receives one notification that the report is ready
And the notification links to the completed report

Scenario: Avoid duplicate notifications
Given a completed report has already sent its ready notification
When the report is viewed again
Then no additional ready notification is sent

Example 6: Bug fix ticket

Acceptance criteria also make bug tickets more precise. Describe the condition that caused the problem and the behavior that confirms the fix.

Jira summary: Prevent duplicate items in a wishlist

Scenario: Add a product once
Given a signed-in shopper has not saved a product
When they select Add to wishlist
Then the product appears once in their wishlist

Scenario: Prevent a duplicate
Given a signed-in shopper has already saved a product
When they select Add to wishlist for the same product again
Then the wishlist still contains one copy of that product
And the user sees that it is already saved

Jira acceptance criteria checklist

• Does every scenario have a clear starting condition, action, and result?
• Can QA verify the result without guessing what the product team meant?
• Are the important validation, permission, and error paths included?
• Do the criteria describe behavior instead of technical implementation?
• Are expected messages, limits, and business rules specific where they matter?