Acceptance criteria generator
Acceptance criteria in Gherkin, from what was actually agreed.
Backlog.cloud generates numbered Given/When/Then scenarios for every user story, derived from the refinement conversation itself rather than a one-line prompt. Being upfront: the free browser tool on this site returns truncated items, and acceptance criteria generation runs inside the product, where it can use the full conversation.
So this page does something more useful than a text box. It shows what good criteria look like, works through a real-shaped example, names the classic failure modes, and gives you a checklist for writing your own.
The standard
What good acceptance criteria actually are
Acceptance criteria are the contract between "we discussed it" and "it is done". Each one is a testable statement of behaviour: a starting state, a trigger, an observable outcome. The Gherkin form makes that structure impossible to dodge. Given names the state. When names the single action. Then names what a tester can see happen.
Three properties separate criteria that work from criteria that decorate. They are numbered, so a code review or bug report can say "AC3 fails" instead of gesturing at a paragraph. Each covers exactly one behaviour, so a scenario passes or fails cleanly. And each is falsifiable, meaning a reasonable person could construct a test that proves it wrong. If no test could ever fail it, it is a slogan.
The deeper point is where criteria come from. A story like "email alerts for saved searches" carries a dozen silent decisions: frequency, grouping, caps, the empty case, duplicates. Those decisions get made in refinement, out loud, and then most teams lose them on the walk back to the keyboard. Criteria are how you keep them.
Worked example
From a refinement exchange to four numbered scenarios
A curated example in the exact shape the product produces. The team is refining a saved-search email alerts story. Watch how every scenario below traces back to a specific sentence in the exchange.
1. What was said in the refinement call
Tomas (PO): The story is the saved-search alerts. Customer sets a search, we email them when new listings match. The bit we went back and forth on last time was frequency.
Leah (Eng): We agreed instant is off the table for launch. Daily digest at 8am in the customer timezone, and only if there is at least one new match. No empty emails.
Tomas (PO): Right. And if they have five saved searches it is still one email, grouped by search, capped at ten listings per search with a view-all link.
Priya (QA): What happens when a listing matches two of their searches? Last time that produced duplicate rows in the digest and a support ticket.
Leah (Eng): Dedupe on listing id across the whole email. It appears once, under whichever search matched first.
2. The acceptance criteria generated from it
Story: Email daily digests of new listings matching saved searches
As a customer with saved searches, I want a daily email of new matching listings, so that I hear about relevant listings without checking the site.
- 1
Given a customer with a saved search and at least one new matching listing since the last digest, When the daily digest job runs at 8am in the customer timezone, Then the customer receives one email containing the new matches for that search.
- 2
Given a customer with five saved searches that all have new matches, When the daily digest is sent, Then all matches arrive in a single email grouped by saved search, with at most ten listings per search and a view-all link for the remainder.
- 3
Given a customer whose saved searches have no new matching listings since the last digest, When the daily digest job runs, Then no email is sent to that customer.
- 4
Given a new listing that matches two of a customer's saved searches, When the digest is generated, Then the listing appears exactly once, under the search that matched first.
The edge case, straight from QA: "What happens when a listing matches two of their searches?"
Every clause has a source. The 8am timezone rule, the ten-listing cap, the no-empty emails decision and the dedupe rule were all said out loud. Nothing was invented to make the list look complete.
Failure modes
The three ways acceptance criteria go wrong
Bad criteria are worse than none, because they create the feeling of rigour without the substance. These three patterns account for most of it.
Criteria that restate the story
"The user can receive email alerts for saved searches."
That is the story again with a full stop on it. It gives QA nothing to test and the developer nothing to check against. If the criterion would be true of any implementation, it is not a criterion.
Untestable adverbs
"Digest emails are sent quickly and reliably, and the layout looks clean."
Quickly compared to what. Reliably measured how. Words like quickly, reliably, intuitively and properly are opinions wearing a criterion costume. Replace each one with a number, a time, or a concrete observable outcome.
Happy path only
Three scenarios about matches arriving, nothing about zero matches, duplicates or timezone boundaries.
The happy path was never in doubt. The empty digest, the listing that matches twice, the customer in UTC+13: that is where the bugs live and where the arguments happen after release. In the example above, the duplicate-listing scenario exists because QA raised it in the call.
Evidence, not prompts
Why criteria from a conversation beat criteria from a prompt
Ask any chat tool to "write acceptance criteria for saved-search email alerts" and it will oblige with confident, generic scenarios. It cannot know your team capped digests at ten listings, or picked 8am in the customer timezone, or decided against instant alerts for launch. So it guesses, and the guesses read well enough that nobody checks them until a developer builds the wrong thing.
Backlog.cloud starts from the other end. The meeting bot sits in the refinement call, or you hand it the transcript or recording afterwards, and it derives criteria from the decisions that were actually made. Each generated story carries the verbatim quotes it was built from. When a reviewer opens the story in the review queue, the question is not "does this sound right?" but "is this what Leah said?", which takes seconds to answer.
It also knows a backlog refinement session from a retro, so it listens for scope decisions, caps and edge cases rather than action items. Approved stories then push to Jira with the numbered scenarios formatted properly in the description. The details are on the meeting to Jira page.
Do it by hand
Writing your own: a checklist that holds up
No tool required. If you are writing criteria by hand after refinement, this list catches most of what goes wrong. Steal it.
- 1
Number every scenario. "AC3 fails" is a sentence people can act on, a wall of prose is not.
- 2
One behaviour per scenario. If you wrote the word "and" in the Then clause twice, split it.
- 3
Given sets state, When is a single action or trigger, Then is an observable outcome. No implementation detail in any of them.
- 4
Write the zero case. What happens when there are no results, no matches, no items.
- 5
Ban adverbs. Anything ending in -ly gets replaced with a number or deleted.
- 6
Read each scenario and ask: could this pass while the feature is still wrong? If yes, tighten it.
- 7
Trace every criterion to something someone actually said or decided. If nobody agreed it, it is your assumption, so flag it as one.
If you would rather the criteria wrote themselves from the call, a free account gets you 3 full generations with acceptance criteria on every story, no card needed. To see the extraction quality first, the free user story generator runs in the browser on pasted notes, with the deep fields shown locked.
FAQ
Acceptance criteria, answered
- Is there a free acceptance criteria generator on this page?
- No, and that is deliberate. The free browser tool on this site returns truncated backlog items with acceptance criteria locked, because criteria generated from a one-line prompt are guesses. Inside the product, criteria are generated from the full conversation, where the frequency rules, caps and edge cases were actually agreed. A free account includes 3 full generations, no card.
- What format do generated acceptance criteria use?
- Numbered Gherkin scenarios: Given a starting state, When an action happens, Then an observable outcome. One behaviour per scenario. Numbering matters because it makes criteria addressable in reviews, test plans and bug reports.
- How many acceptance criteria should a user story have?
- Enough to cover the agreed behaviour and its edges, which usually lands between three and eight. One or two suggests the story has not been thought through. Fifteen suggests it is an epic wearing a story costume and should be split.
- Do acceptance criteria have to use Given/When/Then?
- No, a checklist of testable statements can work for simple stories. Gherkin earns its keep because it forces you to name the starting state and the trigger, which is exactly where vague criteria hide. It also maps directly onto automated test structure if your team uses BDD tooling.
- How does Backlog.cloud generate criteria without me writing a prompt?
- It listens to the meeting, or reads the transcript or recording you give it, and derives criteria from the decisions in the conversation. Each generated story carries the verbatim quote it came from, so a reviewer can check that AC2 reflects what Leah actually committed to, not what a model imagined. Items wait in a review queue and a human approves them before anything is pushed.
- Who should write acceptance criteria, the PO or the developers?
- The honest answer is the conversation writes them. The PO brings intent, engineers bring feasibility and edge cases, QA brings the failure modes everyone else forgot. The dedupe scenario in the example on this page exists because a QA engineer asked an awkward question. Whoever holds the pen, the criteria should record what the room agreed.
- Can generated acceptance criteria go into Jira?
- Yes. Approved stories push to Jira with the numbered scenarios in the description, written in Atlassian Document Format so the formatting survives. The same applies to Azure DevOps, Linear, GitHub Issues, Notion and ClickUp.
Keep going
Related workflows and resources
AI user story generator
The free browser tool: paste notes, get truncated story drafts.
User story artefacts
How generated stories are structured, INVEST checks included.
User stories guide
The long-form guide to writing stories that survive a sprint.
Backlog refinement meetings
What Backlog.cloud listens for in refinement specifically.
Meeting notes to Jira
From a live call to reviewed issues with criteria, in Jira.
Free Jira ticket generator
Paste notes, get Jira ticket drafts in the browser.
Criteria your team agreed, not criteria a model guessed
Create a free account, hand it a refinement call or transcript, and get stories with numbered Gherkin scenarios traced to their source quotes. 3 free generations, no card.