How to Write Acceptance Criteria in Jira—with Practical Examples

“Customers can change their notification preferences” sounds like a clear Jira issue until someone starts building it. Does a change save immediately? What happens if saving fails? Will the preference still be there tomorrow? Which emails are affected?

Acceptance criteria turn those open questions into agreed, observable outcomes. They help the people requesting, building and reviewing a change work from the same expectations.

In this guide, we will develop criteria for a fictional customer portal feature, improve vague requirements and add a practical checklist to Power Pack’s Definition of Done & AC tool. You do not need a special writing format to begin. Clear conditions and results are enough.

What are acceptance criteria?

Acceptance criteria describe the conditions a particular piece of work must meet to be accepted. They focus on the expected result of that item. Atlassian distinguishes them from the Definition of Done, which describes the broader quality standard for completed work. See Atlassian’s acceptance criteria guide.

For our example, “A saved notification choice remains selected after the customer signs in again” is an acceptance criterion. “The implementation has been reviewed” belongs in the shared Definition of Done.

That distinction keeps each list useful. The acceptance criteria explain whether this feature does what the team agreed. The Definition of Done explains whether the work meets the team’s wider completion standard.

Neither list needs to contain every implementation step. “Create a database field” may be a necessary engineering task, but it does not tell a customer or reviewer whether the preference behaves correctly.

Start with one customer outcome

Our fictional issue is called “Let customers control the weekly summary email.” The intended outcome is that a signed-in customer can choose whether to receive a weekly summary without changing essential account messages.

Before writing criteria, the team agrees a few scope decisions. The setting has an explicit Save button. The customer changes only their own preference. The preference affects summaries that have not yet been queued. Messages already queued are outside this issue’s delivery rule.

These details are invented for the example. Your team should decide its actual behaviour rather than copying them as product requirements.

A small scope note can prevent a long checklist from carrying all the context. In the Jira description, the team records that this issue covers one preference on the account-settings page. Choosing delivery days, changing email addresses and managing other customers’ preferences are separate work.

Now the criteria can concentrate on the outcomes that establish whether this particular change works.

Write the normal path first

Start with the experience you expect most customers to follow. State the starting condition, the action and the observable result in ordinary language.

For example: “When a signed-in customer switches weekly summaries off and successfully saves, reopening account settings shows weekly summaries switched off.” A reviewer can create the starting state, perform the action and inspect the result.

That sentence is more useful than “Preferences save correctly.” It specifies which preference changes, when the change takes effect and how someone can check it.

The team also needs the reverse direction. A control that successfully disables summaries but cannot enable them is incomplete. Write a separate criterion when the reverse behaviour deserves its own verification.

Do not force unrelated outcomes into a single entry. Saving, keyboard operation, email delivery and error handling may all matter, but one enormous criterion makes it difficult to show which part still needs attention.

Add failure and boundary cases

The normal path assumes that saving succeeds. Ask what the customer should see when that assumption is false.

Our team chooses this rule: if the save request fails, the page shows an error and does not show a success confirmation. On reopening the page, the previously saved preference remains in place. That gives the reviewer a concrete failure case to exercise in the team’s testing environment.

Next, inspect the boundary of the feature. The weekly-summary setting must not stop a password-reset email. The customer’s choice must also survive a new sign-in session. These are different concerns, so they receive separate criteria.

Avoid writing “All edge cases handled.” Name the cases that matter. A useful discussion often begins with three questions: what might fail, what must remain unaffected and what happens later?

If the team cannot agree an expected result, record the unresolved decision before implementation proceeds too far. An unanswered question does not become a usable criterion merely because it has been placed in a checklist.

A worked acceptance-criteria checklist

Here is the first complete draft for the fictional issue. Each entry describes a result that the team can verify separately.

• Opening account settings shows the customer’s currently saved weekly-summary preference.
• After switching weekly summaries off and successfully saving, reopening account settings shows the preference off.
• After switching weekly summaries on and successfully saving, reopening account settings shows the preference on.
• After a successful save, signing out and signing in again preserves the saved preference.
• If saving fails, an error is shown, no success confirmation appears and reopening settings shows the previously saved preference.
• A customer whose preference is off receives no weekly summary newly queued after the successful save.
• A customer whose preference is on remains eligible for the next weekly summary under the existing scheduling rules.
• Turning off weekly summaries does not prevent that customer from receiving a requested password-reset email.

The delivery entries depend on the scope decision about queued messages. The team records that context alongside the issue so the reviewer does not assume the setting recalls emails that are already being sent.

These criteria also need a workable verification approach. For the delivery behaviour, the team identifies how to trigger or observe a summary in its test environment. A criterion can be clearly written yet difficult to verify if nobody has access to the necessary account or delivery evidence.

Improve vague criteria before adding them

A quick wording review often prevents longer disagreements later. Read each entry and ask whether two people could interpret success differently.

The last example does not prove usability by itself. It replaces one vague sentence with one useful, limited check. Broader usability goals may need research or several agreed observations.

Be careful with invented precision, too. Adding a two-second response requirement sounds measurable, but it creates a real commitment. Agree the conditions and reason for a performance threshold before including it.

Put the criteria into Power Pack

Open the Jira issue and find the Definition of Done & AC card. Select the Acceptance Criteria tab. Its list is separate from the Definition of Done tab, so check the selected tab before entering content.

To add a single criterion, type its title and select Add or press Enter. Use concise titles that still preserve the expected outcome. If a criterion needs extensive context, keep that context in the Jira description or the team’s linked documentation.

For several entries, select Bulk Import and paste a Markdown bullet list. You can copy the example entries above, placing a hyphen and space before each one. Markdown checkbox lists are also supported.

Review the resulting entries after import. The action appends to the current list, so importing the same checklist again can create entries already present. Checked Markdown checkbox entries arrive marked done; begin with unchecked entries unless the current issue’s outcomes have actually been verified.

If an entry is wrong, review the replacement wording with the team, add the corrected entry and delete the obsolete one using its confirmation prompt. Keep the issue’s supporting discussion clear when a change affects the agreed scope.

Review outcomes before marking them done

Before implementation, ask someone involved in verification to walk through the proposed criteria. They may spot missing starting conditions or an outcome that cannot be observed with the available test setup.

After implementation, verify each result and record evidence through the team’s normal Jira or documentation process. Select an item’s Done button when the agreed outcome has passed. Selecting it again returns it to todo if a later finding reopens the check.

For example, the preference may survive a page reload but reset after a new sign-in. The page-reopening criterion can pass while the session-persistence criterion remains incomplete. Separate entries preserve that useful distinction.

Power Pack tracks checklist completion; it does not execute the tests or automatically establish who reviewed them. If the review requires named verification or a dated result, record those details explicitly in your normal process.

Use both counts without mistaking them for proof

Acceptance Criteria and Definition of Done each show their own completed and total counts. The readiness indicator shows Ready for Release only when both lists are nonempty and every entry in both is done. Otherwise, it shows In Verification.

That is a summary of the entered checklist state. It cannot establish that the criteria cover every important behaviour or that the supporting evidence is sound. It also does not enforce Jira workflow transitions or block merges.

Our notification issue might have all eight acceptance criteria complete while support guidance remains unfinished in Definition of Done. The feature outcomes have passed, but the team’s wider completion agreement still has an open item.

Start with one upcoming Jira issue. Write the customer outcome, agree the important conditions and results, then add the criteria to Power Pack alongside the shared Definition of Done. Review the list with the people who will build and verify the change. The payoff is fewer assumptions hiding behind a sentence that initially sounded obvious.

• Atlassian — What is Acceptance Criteria?