Acceptance Criteria Generator

Feature or story:

Use the ticket title or feature name reviewers will recognize.

Actor:

Keep it role-based, such as account admin, API client, or warehouse operator.

User outcome:

Describe the value reviewers should observe, not an internal implementation task.

Expected behaviors:

Each unique nonblank line becomes one positive acceptance criterion.

Edge cases and rules:

Each unique nonblank line becomes one negative or boundary criterion.

Draft format:

Use Gherkin for scenario review, checklist for grooming, or contract for a QA handoff brief.

Review layer:

This changes the generated Given and Then evidence, not only its label.

Criteria ID prefix:

Letters, digits, underscores, and hyphens are normalized to uppercase.

Starting number:

Accepted values are whole numbers from 1 through 999.

Add quality criteria:

Off preserves the supplied behavior and boundary rows unchanged.

{{ params.include_quality_criteria ? 'Included' : 'Not included' }}

{{ values.draft_text }}

ID	Type	Given	When	Then	Copy
{{ row.id }}	{{ row.type }}	{{ row.given }}	{{ row.when }}	{{ row.then }}

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

Teams can agree on a feature name while disagreeing about what evidence will count as done. Acceptance criteria turn an intended outcome into boundaries that a product owner, developer, tester, and reviewer can discuss before implementation choices harden.

Good criteria sit between a broad user story and detailed test cases. A user story names the actor and desired value; acceptance criteria state the behavior that must be observable; test cases later add concrete data, setup, and execution detail. Mixing those layers too early can make the requirement brittle or hide the actual business rule.

Part	Question it answers	Useful wording
Context	What must already be true?	A known state, permission, record, or eligibility condition.
Event	What action or event occurs?	One specific behavior with a clear trigger.
Outcome	What can a person or external system observe?	A status, message, response, handoff, or prevented change.
Boundary	When must the normal path change?	A limit, invalid state, permission loss, timeout, or duplicate action.

Positive paths alone rarely define a feature. Permission failures, unavailable dependencies, repeated submissions, and limits often determine whether the result is safe to release. Those cases should name the expected response and any state that must remain unchanged.

Acceptance criteria are still a conversation, not an automatic verdict. Generated wording can expose missing categories and create a consistent draft, but only people who understand the product can confirm that the rules are complete, feasible, and aligned with the intended outcome.

How to Use This Tool:

Start with one feature and one actor, then supply one observable behavior or boundary per line.

Enter the Feature or story, the Actor, and the intended User outcome. Describe value rather than an implementation method.
List expected behaviors, edge cases, and rules on separate lines; blank and repeated lines are removed. Then choose Gherkin scenarios, a checklist, or a QA handoff contract and select the matching review layer.
Review the summary and Review checklist. Replace vague words with visible states, messages, limits, or measurable outcomes before handing the draft to the team.

Interpreting Results:

Ready means the built-in review found no missing negative coverage, absent outcome, failed scenario shape, or common vague wording. It does not mean the criteria are correct for the product. Review needed points to one or more drafting gaps that should be resolved before grooming or QA handoff.

Positive, negative, and quality counts describe the mix of generated rows. A balanced-looking chart is not a target: a narrow change may need one strong negative case, while a permission-heavy workflow may need several. Judge each row by whether its context, trigger, and outcome are independently understandable and testable.

Technical Details:

The drafting model is deterministic. It normalizes whitespace, removes blank or case-insensitive duplicate lines, and converts the remaining behavior and edge-case cues into one canonical set of scenario rows. The selected output format changes presentation, not the underlying criteria.

Rule Core:

Input or option	Construction rule	Result
Expected behavior line	Remove leading modal verbs such as “can,” “should,” or “must,” then place the action into a Given–When–Then row.	One positive criterion.
Edge case or rule line	Use the edge case as the condition and the first positive action as the attempted behavior.	One negative criterion with a generic block-or-redirect outcome.
Add quality criteria	Append fixed checks for accessible feedback and operational evidence.	Exactly two quality criteria.
ID settings	Keep letters, numbers, underscores, and hyphens; uppercase the prefix; start from an integer from 1 to 999; pad numbers to at least two digits.	Sequential IDs such as `AC-01`.
Draft format	Render the same canonical rows as Gherkin, a checkbox list, or a QA handoff contract.	Different document shapes with the same generated behavior set.

The review layer supplies a different context and expected-evidence phrase. Product emphasizes visible behavior, interface review emphasizes accessible controls and state changes, API review emphasizes status and response contracts, and workflow review emphasizes ownership and handoff state.

Six review signals are evaluated. Behavior coverage and scenario shape pass when rows exist. Negative coverage requires at least one supplied edge case; actor and outcome review flags an empty outcome; a vocabulary scan flags terms such as “fast,” “secure,” “simple,” or “user-friendly”; and the quality row reports whether the optional pair was added. These are drafting heuristics, not semantic analysis.

Limitations and Privacy Notes:

The generator cannot discover missing business rules, verify feasibility, infer exact thresholds, or decide whether a negative outcome should block, retry, compensate, or escalate. Its negative rows use a general safe-state sentence, which should be replaced with the actual product response.

Story text is processed in the browser. Even so, requirements may contain customer names, incident details, unreleased plans, or security-sensitive behavior. Remove unnecessary confidential data before copying or exporting a draft.

Worked Example:

For an export retry flow, “Retry a failed export from history” becomes a positive row. “Completed exports cannot be retried” becomes a negative row that starts from the completed condition. The draft is useful for discussion, but the team must still replace the generic blocked-flow outcome with the exact message, HTTP response or interface state, and confirm that no duplicate file is created.

References:

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