Acceptance Criteria Generator

Feature or story:

Use the ticket title or feature name reviewers will recognize.

Actor:

Keep it role-based, for example account admin, API client, or warehouse operator.

User outcome:

This becomes the acceptance context, not a hidden implementation detail.

Expected behaviors:

Each line becomes one positive acceptance criterion.

Rows stay local and recompute instantly.

Edge cases and rules:

Each line becomes a negative or boundary acceptance criterion.

Draft format:

Gherkin works best for QA automation handoff; checklist works best for backlog grooming.

Criteria ID prefix:

Use a short ticket or project prefix, for example AC, PAY, or API.

Starting number:

Use this when adding criteria to an existing ticket.

first ID

Test layer:

Leave as product review unless the ticket is specifically API, UI, or workflow focused.

Add quality criteria:

Off keeps the draft focused on the supplied behaviors and edge cases.

Check acceptance inputs

{{ error }}

{{ result.draftText }}

ID	Type	Given	When	Then	Copy
{{ row.id }}	{{ row.typeLabel }}	{{ row.given }}	{{ row.when }}	{{ row.thenText }}
No scenario rows available Add at least one expected behavior to generate criteria.

Review point	Status	Evidence	Next action	Copy
{{ row.point }}	{{ row.status }}	{{ row.evidence }}	{{ row.action }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Acceptance criteria give a backlog item a pass-or-fail boundary. A user story may explain who needs a capability and why it matters, but the criteria state what must be true before the work can be accepted. Good criteria make review less dependent on memory, optimism, or private assumptions about how the feature is supposed to behave.

The useful unit is an observable condition. A criterion should name the situation, the trigger, and the evidence a reviewer can see in a screen state, response, message, notification, audit record, exported file, or handoff state. Vague words such as fast, secure, simple, and user-friendly do not give a team enough to accept or reject the work unless they are tied to thresholds, states, messages, or measurable outcomes.

Backlog terms compared with acceptance criteria
Term	Main job	Common mistake
User story	Frames the actor, need, and value behind a backlog item.	Treating the story sentence as enough detail for acceptance.
Acceptance criteria	Define item-specific conditions that must be true before the item can be accepted.	Combining setup, action, failure behavior, and reporting into one broad rule.
Definition of Done	Sets the shared quality bar that completed work must meet.	Using a team-wide quality standard as a replacement for story-specific behavior.
Test case	Turns a criterion into exact test data, steps, and assertions.	Writing test mechanics before the acceptance rule is clear.

Given-When-Then language is popular because it keeps a scenario small. Given fixes the known state, When names one event, and Then states the expected result. A scenario usually becomes harder to review when it tries to cover permissions, validation, retries, notifications, and data retention in the same row.

Boundary cases are where acceptance criteria often earn their keep. Permissions, invalid input, duplicate actions, unavailable states, retention windows, recovery paths, and handoff failures decide whether a feature is safe to accept when the happy path already works. Positive criteria describe the expected path; negative criteria protect the product from false confidence.

Acceptance criteria still need conversation. They are a compact agreement about observable behavior, not a substitute for product judgment, domain knowledge, or tester review. The team still has to decide whether each condition is valuable, testable, and small enough to support a clear acceptance decision.

How to Use This Tool:

Enter the story context first, place one behavior or edge case on each line, then use the draft and checklist tabs to tighten the pack before sharing it.

Fill Feature or story with the ticket title, capability, or workflow reviewers will recognize.
Set Actor and User outcome. These values shape the story line and keep the generated criteria tied to a role and an acceptance reason.
Add one observable success behavior per line in Expected behaviors. Each unique non-blank line becomes one positive criterion.
Use Edge cases and rules for blocked states, validation failures, permission changes, duplicate actions, limits, retention windows, unavailable states, and recovery behavior. Each unique non-blank line becomes one negative criterion.
Choose Draft format. Gherkin scenarios creates feature-style text, Criteria checklist creates Markdown checkbox lines, and QA handoff contract expands each row with type and source cues.
Open Advanced when you need a custom ID prefix, a different starting number, a product, UI, API, or workflow review lens, or optional accessibility and operational evidence rows.
Use Normalize after rough entry to clean spacing, remove duplicate behavior and edge-case lines, normalize the ID prefix, and keep the starting number inside the accepted range.
Review Criteria Draft, Scenario Ledger, and Review Checklist before copying or downloading. Fix required-input alerts first, then rewrite any review warnings into sharper criteria.

Interpreting Results:

The summary status is a drafting signal, not an acceptance decision. Needs input means a required field is missing, usually the feature, actor, or at least one expected behavior. Review needed means rows were generated, but a review check still needs attention. Ready for grooming means required fields are present and no generated review row is marked Review or Fail.

Read counts as coverage clues. A pack with many positive rows can still miss permission failures, duplicate actions, unavailable states, or validation cases. A zero negative count should trigger another pass before sprint commitment because happy-path criteria rarely describe enough risk by themselves.

The Review Checklist points to likely corrections. Behavior coverage checks whether expected behavior lines exist. Negative coverage checks whether edge cases exist. Specific language warns about common vague words such as fast, secure, simple, robust, and user-friendly. A pass on that wording check only means those common terms were not found; it does not prove every Then statement is measurable.

Before treating a draft as acceptance evidence, scan each Scenario Ledger row and ask whether a reviewer could verify the Then result from a visible screen state, response body, message, audit entry, notification, exported file, or handoff state. If the answer depends on team interpretation rather than visible evidence, rewrite the row.

Technical Details:

Acceptance criteria work best as small decision rules. Each rule connects a context to one event and one expected result. The rule should be specific enough to reject incomplete work, but not so broad that several behaviors hide inside the same sentence.

Given-When-Then scenarios mirror acceptance-test reasoning. The known state comes first, the event follows, and the expected outcome is checked against something observable. That shape can support manual review or later automation, but executable tests still need step definitions, data setup, and assertions outside the acceptance draft.

Rule Core:

Acceptance criteria generation rules
Input cue	Rule applied	Review consequence
`Expected behaviors`	Every unique non-blank line becomes a `Positive` criterion with an ID, title, Given, When, Then, and source cue.	Each row should describe one behavior that helps the actor reach the stated outcome.
`Edge cases and rules`	Every unique non-blank line becomes a `Negative` criterion that starts from the boundary condition and blocks unintended state change.	Boundary rows should cover invalid input, permission changes, duplicates, limits, unavailable states, and recovery paths.
`Add quality criteria`	When enabled, two `Quality` rows are added for accessible feedback and operational evidence.	The extra rows are useful when focus, status messaging, audit trails, notifications, or history records affect acceptance risk.
`Test layer`	The scenario wording changes for product review, UI behavior, API contract, or workflow handoff.	The same behavior cue can be pointed at the most relevant acceptance surface.
`Criteria ID prefix` and `Starting number`	The prefix is uppercased after non-ID characters are removed. The first number is rounded and bounded from 1 to 999, then displayed with at least two digits.	IDs can continue an existing ticket sequence while staying stable for review notes and copied rows.

The draft has three text shapes. Gherkin scenarios groups rows under a feature and creates one scenario per criterion. Criteria checklist compresses each row into a Markdown checkbox. QA handoff contract expands each row with its type and source cue so a tester can see why the criterion exists.

Review Signal Map:

Acceptance criteria review signal meanings
Review point	What changes the status	How to correct it
`Behavior coverage`	No expected behavior line exists, or the behavior count needs review.	Split broad requirements into one observable behavior or outcome per line.
`Negative coverage`	No edge case or rule line exists.	Add validation, permission, unavailable-state, duplicate-action, limit, or recovery cases.
`Actor and outcome`	The actor or outcome is incomplete.	Use a role-based actor and a concrete value statement before handoff.
`Given-When-Then shape`	The generated pack has no scenario rows or required fields are missing.	Restore required inputs and rewrite any row whose trigger or expected result cannot be checked independently.
`Specific language`	Behavior or edge-case cues include common vague words.	Replace fuzzy wording with thresholds, states, messages, response fields, visible output, or reviewable time windows.
`Quality criteria`	The optional quality rows are either included or left out.	Turn them on when accessibility feedback or operational evidence should be explicit in the acceptance conversation.

Criteria IDs are labels, not priorities. Changing the prefix or starting number changes how rows are referenced in tickets, review comments, exports, and copied text; it does not change the scenario logic. Duplicate behavior lines and duplicate edge-case lines are collapsed before rows are generated, which prevents repeated criteria from making the pack look more complete than it is.

The draft cannot infer hidden business rules, inspect a ticket, validate product strategy, or prove a scenario can be automated. It organizes supplied context into a consistent criteria pack and highlights gaps that still need product, engineering, and QA judgment.

Privacy Notes:

The visible drafting, review checks, copy actions, and downloads are generated from the text entered on the page. There is no account lookup or ticket-system connection, so the page cannot read private backlog details unless they are pasted in. Avoid entering secrets, customer personal data, production credentials, or confidential incident details in examples; use role names, states, and representative values instead.

Worked Examples:

For an export retry story, Feature or story can be Export retry flow, the Actor can be account admin, and the outcome can focus on recovering from transient export failures without creating duplicate files. Three behavior lines and three edge-case lines produce six Scenario Ledger rows: three Positive and three Negative. With prefix AC and starting number 1, the first row is labeled AC-01.

An API token rotation item might use API client as the actor, behavior lines for requesting a new token and seeing the old token expire, and edge cases for missing authorization or expired credentials. Setting Test layer to API contract moves the wording toward request data, response status, response body expectations, and idempotency checks while keeping the same row structure.

If a team needs explicit QA depth for a risky admin workflow, turning on Add quality criteria adds rows for accessible feedback and operational evidence. A draft with two behavior lines, one edge case, and that option enabled produces five criteria total. Those quality rows should be checked against the team's Definition of Done rather than treated as replacements for feature-specific behavior.

A troubleshooting pass often starts with Needs input. If Expected behaviors is empty, Criteria Draft asks for at least one behavior and Review Checklist marks Behavior coverage as Fail. Add one observable behavior, then confirm that Scenario Ledger has rows and the first alert no longer names the missing input.

FAQ:

Why did the draft create more criteria than I expected?

Each unique behavior line and each unique edge-case line becomes its own criterion. If Add quality criteria is on, two more rows are added for accessible feedback and operational evidence.

Why is negative coverage marked for review?

Edge cases and rules is empty. Add blocked states, validation failures, permission changes, duplicate actions, limits, retention windows, or recovery cases before relying on the criteria for sprint commitment.

Can the Gherkin draft become automated tests?

It can become a starting point, but it is not executable test code by itself. Automation still needs step definitions, test data, assertions, and agreement that the scenario wording matches the product domain.

What does Normalize change?

It trims spacing, removes duplicate behavior and edge-case lines, sentence-cases those lines, lowercases the actor, normalizes the ID prefix, and bounds the starting number between 1 and 999.

Why did the specific-language check warn about my text?

One or more supplied cues contains a common vague term such as fast, secure, simple, robust, or user-friendly. Replace that wording with a visible state, threshold, message, response field, audit record, or time window.

Should technical tasks be written as acceptance criteria?

Usually no. Keep the story, actor, outcome, and behavior lines focused on what a reviewer can observe. Technical tasks can live in delivery notes unless a technical contract, such as an API response, is itself the accepted behavior.

Glossary:

Acceptance criteria: Item-specific conditions that must be true before a backlog item can be accepted.
User story: A short description of who needs a capability, what they need, and why it matters.
Given-When-Then: A scenario pattern that separates known state, trigger, and expected result.
Positive criterion: A criterion generated from an expected behavior that should succeed.
Negative criterion: A criterion generated from a boundary case where the product should block, redirect, or explain the result.
Quality criterion: An optional criterion for accessible feedback or operational evidence during QA handoff.
Definition of Done: The shared quality standard an increment must meet to be considered complete.
Scenario Ledger: The result table that lists each generated criterion with its ID, type, Given, When, and Then text.

References:

Gherkin Reference, Cucumber.
Agile Glossary, Scrum Alliance.
User Stories, Agile Alliance.
The Scrum Guide, Scrum Guides, November 2020.