How to write Jira tickets with testable acceptance criteria on Mac, step by step

What makes an acceptance criterion testable

A testable acceptance criterion describes one behavior you can observe. A tester reads it, runs the feature, and answers yes or no. The line 'the page should load quickly' fails that test. Quickly means something different to every person who reads it.

The fix is not a longer sentence. The fix names the starting state, the trigger, and the result. Someone can test that in a few minutes, without a meeting, and without guessing what you meant.

Why vague Jira tickets happen

Vague tickets are common, and they are not a personal failing. In the NaPiRE survey, 48% of 228 organizations named incomplete or hidden requirements as a problem. Another 33% named requirements that were too abstract and allowed several readings.

That survey ran from 2014 to 2015, and it covers requirements work in general, not Jira tickets. Treat it as a pattern. It does not tell you how often your team writes vague lines.

A second study looked at non-functional requirements, such as speed, security, and accessibility. Its authors found that 78% of 41 rework tasks came from avoidable gaps in shared understanding. Those gaps were avoidable, not bad luck.

Be careful with the claim that a bug costs far more to fix late. A 2016 study of 171 projects found no evidence for that delayed-issue effect. You do not need that claim to justify better tickets. Count the rework in your own sprint comments instead.

How to structure a Jira ticket with acceptance criteria

A ticket that holds up under testing has a few clear parts. Each part answers a question that a developer or tester would otherwise ask you in Slack. Write them in this order, and keep the headings short.

1. Outcome: why this work exists, in one sentence a customer would recognize.
2. Scope: the user, the screen, and the rule that changes.
3. Acceptance criteria: observable behaviors, written as a checklist.
4. Out of scope: what the team should not build in this ticket.
5. Test notes: sample data, roles, and the edge cases that worry you most.

Coverage matters more than the exact order. Skip a part and someone will ask about it later. The part people skip most is out of scope. Without it, the criteria grow during the sprint, one reasonable request at a time.

Given When Then acceptance criteria, and when to skip them

Given When Then is a format for behavior. Given sets the starting state. When names the action. Then names the result you can see. It works well for flows that have a trigger, such as password reset or checkout.

Given a user has requested a password reset, when they open the link after it expires, then they see a message that the link is no longer valid and can request a new one.

Plain checklists work better for rules and limits. Examples include which roles can export data, or which fields are required on a form. Forcing those rules into Given When Then makes them longer, not clearer.

Pick one style per ticket and keep it. Mixing styles in one list makes testers slow down to decode the format. Consistency is easier to keep when the same template holds the headings.

A worked example of rewriting a vague Jira ticket

Start with a ticket most teams have seen. The title says Improve password reset. The description says users find the process confusing and support gets too many emails. Nothing in that text lets a tester say pass or fail.

Rewrite it by asking what the user sees and what the system stores. Then list the states that exist. A registered user, an unknown email, an expired link, a used link, and a double click each need an answer. Each answer becomes one line.

• Given a registered email, when the user requests a reset, then they receive one email with a link.
• Given a link older than the expiry window, when the user opens it, then they see an expired-link message and a button to request a new link.
• Given an email that is not registered, when the user requests a reset, then the page shows the same confirmation as for a registered email.
• Given a link that was already used, when the user opens it, then the new password form does not appear.
• Out of scope: changes to the email template and to the sign-in page.

The third line is the one most people miss. It stops the reset page from revealing which emails have accounts. Ask your engineering lead to confirm the wording, because the product owns the behavior while engineering owns the security review.

Set up a Jira description template on Mac

Jira Cloud runs in your browser, so Mac users work in Chrome or Safari. Atlassian says support has ended for the Jira Cloud for Mac app, and version 148 is the final update. Open your board in the browser, then press ⌘ D to bookmark it.

A template keeps the format in front of you each time you create a ticket. Atlassian describes two methods for a default description in Jira Cloud. The first uses Automation for Jira, with a rule that runs when a work item is created.

That rule sets the description to the existing text plus your template, using the {{issue.description}} placeholder. The second method is the third-party Default Values app from the Atlassian Marketplace. It pre-fills the description on the create screen.

Check with your Jira admin before you install any app, because your company may limit what can be added. Atlassian's article applies to Cloud only. It does not say which project types each method supports, so test in a sandbox project first.

1. Ask your Jira admin which method your site allows.
2. Use a sandbox project that nobody else uses for real work.
3. Add the rule or app setting that puts your headings in the description.
4. Create a ticket and confirm the headings appear in the description box.
5. Edit the ticket and confirm your text is kept, not replaced.
6. Delete the sandbox project when the test is done.

Use Rovo to generate acceptance criteria in Jira, then check them

Atlassian's Rovo can generate acceptance criteria from a work item description. Open the description editor and use the Rovo icon, or type /rovo or /ai. Then choose the option to generate acceptance criteria from the work item description.

The generated text can be edited like any other text. Atlassian's support page does not say which plans or access levels include this action. Confirm it on your site before you plan a rollout.

Treat the output as a first draft. Check every generated line against the design, the data, and what engineering can build. A draft can invent a limit or a role that nobody agreed on. Delete any line you cannot trace to a source.

Review the criteria with engineering and QA before the sprint

A short review catches many gaps before work starts. Read each criterion aloud with one developer and one tester. Ask the tester how they would check it. If the tester pauses, the line is not ready.

The review should stay on the criteria, not the solution. The developer can propose the approach later. Keep the meeting short, and keep a note of each rewrite so the same gap does not come back.

• Judgment words like fast, easy, clean, or intuitive, with no check attached.
• Criteria that describe a task, such as build the table, instead of a behavior.
• No out of scope section, or one that says nothing useful.
• Criteria added after the work started, without a note on why.
• One ticket that describes several separate features.

Common mistakes with acceptance criteria in Jira

The first mistake is writing the solution as the criterion. The line 'Add a dropdown' tells engineering what to build, but not what a user should be able to do. Describe the result, then let engineering pick the control.

The second mistake is writing criteria after the build. Criteria written from finished code tend to describe what was built. Write them first, then ask whether the build matches them.

The third mistake is copying criteria between tickets. Two tickets can look alike and differ in one rule. A copied line carries the wrong rule into the second ticket, and nobody notices until testing.

The fourth mistake is skipping edge cases because they feel minor. Edge cases generate many of the support questions after release. Ask what happens with empty input, missing permission, and a dropped connection.

Where Lazur helps with ticket writing, and where it does not

Lazur is a voice assistant for the Mac. Hold a key and talk. It sees your screen only while you hold the shortcut, and it answers out loud. It can point at things, guide you one click at a time, and type drafts at your cursor.

It does not click buttons for you, edit Jira, or write into your ticket on its own. You still paste, save, and review. Hold ⌥⌘ to ask about anything on screen. Hold fn to dictate clean text at the cursor in any app.

Dictation suits ticket writing, because you can speak the outcome, the users, and the edge cases faster than you type them. Then edit the words yourself. Dictation can mishear product names, so check feature names and rule wording.

For confusing text, hold ⌥⌘ over the criterion and ask Lazur to explain it in plain words. For a first draft from your notes, ask it to draft criteria. Check every line before you paste it into Jira.

Privacy matters when tickets hold customer details or unreleased plans. Lazur sends audio and the screenshot to AI providers to answer, and they are not stored. Content is never used to train AI models. If your employer limits where work data can go, follow that rule first.

What the evidence on vague tickets does not show

The research base is thinner than the advice. The NaPiRE figures come from 2014 and 2015. The Atlassian survey is run by a vendor and measures general non-coding friction, not ticket quality.

That survey reports that 90% of respondents lose 6 or more hours a week to non-coding work. The same report says 63% of respondents think leaders do not understand their pain points, up from 44% in 2024. Those figures do not show that vague tickets cause either problem.

No controlled study found here shows that acceptance-criteria formats or templates reduce rework. The fixes in this guide are working habits, not proven methods. Measure your own sprints before and after you change anything.

What to do next

Pick one ticket from this week and rewrite its criteria with the format above. Then run the short review before the next refinement. For the wider routine, read how product managers use Slack and Notion for PRD workflows.