Feed an AI your Jira issue’s summary and description, and it generates 4-5 discrete, testable acceptance criteria in Given/When/Then form — happy path, edge cases, and negative scenarios — before anyone writes code. That’s what an acceptance criteria generator is for, and the timing is the whole point. A defect caught while you’re still shaping the requirement costs almost nothing to fix; the same defect caught in production costs orders of magnitude more.

Why generate acceptance criteria before code, not after?

Because that’s where defects are born and where they’re cheapest to kill. Jama Software’s requirements guide reports that defects caused by poor requirements can consume up to 85% of project rework costs. The cost curve is brutal downstream: the IBM System Science Institute data, summarized by Functionize, shows a bug found in testing costs roughly 15x more than one caught in design — and up to 100x more in production. Writing acceptance criteria forces the ambiguity out of a ticket before it becomes committed code. AI just makes that step fast enough that people actually do it.

What does a good acceptance criterion look like?

Given/When/Then — one line per behavior, each mapping directly to a test. Xray’s documentation treats each acceptance criterion as a sub-requirement that a test covers, so coverage on the parent story rolls up from the criteria beneath it. Vague criteria (“login should work”) break that chain. A criterion is good when a QA engineer who’s never seen the feature can read it and know exactly what to click and what to expect.

A complete set covers three kinds of behavior, not just one:

  • Happy path — the feature working as intended for the main case.
  • Edge cases — the boundaries: empty inputs, limits, expired states, the maximum value plus one.
  • Negative scenarios — what happens when something goes wrong: bad input, missing permission, a duplicate submission.

Most hand-written criteria stop at the happy path — which is exactly the gap AI closes, because you can ask it for all three. Sanity-check the set against INVEST too: each criterion should be independent, testable, and small enough to verify in one action. If a “criterion” needs three separate tests to prove, split it.

Acceptance criteria vs. definition of done — what’s the difference?

They get conflated, and a generator only produces one of them. Acceptance criteria are per-story — the specific, testable conditions that prove this feature behaves correctly. The definition of done is one team-wide checklist that applies to every story: tests written, code reviewed, documentation updated, deployed to staging. You regenerate acceptance criteria for each ticket; your definition of done is a fixed standard you set once and reuse. Ask an AI for acceptance criteria and you should get story-specific behavior, not a generic “code is reviewed and merged” list — if it hands you the latter, your prompt is too vague.

How do you turn a one-line description into criteria?

Here’s a real example. You start with a description a PM might paste into a ticket:

As a user, I want to reset my password by email so I can get back into my account.

Feed that to an AI with the instruction “write acceptance criteria in Given/When/Then,” and you get testable behavior:

1. Given a registered user on the login page,
   When they click "Forgot password" and enter a valid email,
   Then a reset link is sent and a confirmation message is shown.

2. Given a user enters an email not tied to any account,
   When they submit the reset form,
   Then the same generic confirmation is shown (no account enumeration).

3. Given a user clicks a reset link older than 60 minutes,
   When the page loads,
   Then the link is rejected and they are prompted to request a new one.

4. Given a user on the reset page enters a password under 8 characters,
   When they submit,
   Then the form is blocked and the length rule is shown inline.

5. Given a user completes a valid reset,
   When they return to login,
   Then the old password fails and the new password succeeds.

Notice criteria 2 and 3 — account enumeration and link expiry. Nobody wrote those in the one-line description. The AI surfaced the edge cases the PM skipped, which is exactly the requirements-phase defect you want to catch before a developer guesses wrong.

A copy-paste prompt that works

The reason that example produced edge cases instead of a wall of happy-path restatements is the prompt named the scenario types explicitly. Steal this:

Here is a Jira user story:
[paste summary + description]

Write 5 acceptance criteria in Given/When/Then format.
Include: 1 happy path, at least 2 edge cases, and 1 negative/error case.
Each criterion must be independently testable in a single action.
Do not restate the same behavior twice.

Fix the count, name the three scenario types, and demand testability — those three constraints are what separate a useful draft from generic filler. If you write the ticket description itself with AI first, the same idea applies at that step too.

How to generate them in Jira, step by step

  1. Open the issue and make sure the summary and description hold enough context — a sentence of intent beats a two-word title.
  2. Trigger the AI from the issue (via an app that reads the ticket’s fields directly, so you’re not copy-pasting into a separate chat window).
  3. Ask for 4-5 criteria in Given/When/Then. Specify the count — otherwise you get a wall of overlapping statements.
  4. Cut and edit. The AI over-produces. Delete criteria that restate the same behavior, and add any domain rule it couldn’t know.
  5. Paste into the acceptance criteria field (or push each as a sub-task if you follow Xray’s coverage model), then link your tests.

Doesn’t Atlassian’s built-in AI already do this?

Partly, and that’s the gap. Atlassian’s Rovo markets AI that generates issue descriptions and restructures vague tickets, and it can validate a pull request against criteria already stored in an issue. But “acceptance criteria” isn’t a headline output Atlassian owns a doc for — the generation step, in strict Given/When/Then, tuned to your team’s format, is still open ground. That’s the specific job dedicated marketplace apps target. (We break down where the built-in AI stops in Rovo vs. Copilot for Jira teams, and what Rovo’s metered credits cost you per request in Atlassian Rovo pricing, explained.)

The honest funnel

AI Copilot for Jira does this one job well: it reads the issue you’re already looking at and drafts acceptance criteria in Given/When/Then, right in the ticket, so you’re editing a draft instead of staring at an empty field. It won’t replace your judgment about which edge cases ship-block — nothing should. But if your team keeps skipping acceptance criteria because writing them from scratch is a chore, the app removes the chore, and the requirements-phase defects it surfaces are the cheapest bugs you’ll ever fix. Try it on your next five tickets and see how many edge cases it catches that you’d have found in QA instead.