To create user stories and acceptance criteria with AI, begin with verified user evidence, state the actor and goal, split work into reviewable outcomes, and write criteria that an authorized person can observe and decide. AI should expose missing assumptions and edge cases; it should not invent user needs, choose implementation details, or approve the requirement.

Key Takeaways

Trace every story to a verified need, problem, policy, or operational constraint.

Focus the story on the user’s goal rather than a requested feature or interface.

Cover normal, boundary, failure, permission, accessibility, privacy, and security outcomes.

Keep acceptance criteria, implementation tasks, test cases, and Definition of Done distinct.

The general AI workflow supplies the source, review, and approval controls. For broader sequencing and ownership, see building a project plan with AI; a user story is not a miniature project plan.

What evidence should come before a user story?

Collect the evidence that explains the user, problem, desired outcome, constraints, and unresolved questions. Sources may include approved research findings, support patterns, analytics, policy requirements, accessibility findings, incident reports, or an explicitly owned business rule.

Create an evidence packet:

Evidence ID	Source	Observed need or constraint	Population/context	Confidence	Owner
E-014	moderated research finding	users cannot tell whether submission succeeded	first-time applicants	medium	research lead

Separate evidence from proposed solutions. “Users need confirmation that their submission was received” describes an outcome. “Show a green toast for five seconds” is one implementation idea and should not become the user need by default.

Do not provide confidential recordings, personal data, security details, or unrestricted internal documents to an AI service. Use the smallest approved excerpts and stable evidence IDs.

How do you write a goal-oriented user story?

GOV.UK says user stories should identify the actor, what the user needs, and the goal, commonly using “As a… I need/want/expect to… So that…”. It emphasizes that the goal is the most important part.［1］

Use a story canvas before generating prose:

Field	Question
actor	who experiences the need, without inventing a persona?
context	when and where does the need arise?
need	what outcome must the user achieve?
goal	why does that outcome matter?
evidence	which IDs support the story?
constraints	policy, accessibility, privacy, security, or operational boundaries?
assumptions	what has not been verified?
approver	who owns the product decision?

Then ask AI for alternatives:

Draft three user-story candidates from this evidence packet. Each must state the actor, need, and goal; cite the supporting evidence IDs; avoid interface and implementation choices; list unsupported assumptions; and explain when the story should be split or rejected. Do not invent user research or treat stakeholder preference as user evidence.

Review whether the actor is real and relevant, the goal is outcome-oriented, and the story can be discussed without prescribing the solution.

How do you split an epic or oversized story?

GOV.UK describes large stories that take more than a few weeks as epics and recommends splitting them into smaller stories that can be completed within an iteration when possible.［1］ Do not split only by technical layers such as database, API, and interface; that can leave each story without independent user value.

Useful splitting dimensions include:

distinct user goals or journey stages;
happy path versus recoverable exception path;
read versus create versus change outcomes;
permissions or actor types;
simple case before complex variation;
supported channels or policy jurisdictions;
manual review before safe automation.

Keep cross-cutting constraints visible in every affected story. A privacy, accessibility, or authorization requirement should not disappear because the work was split.

What makes acceptance criteria observable?

Acceptance criteria describe the conditions or outcomes that must be satisfied for an authorized user, customer, or other entity to accept the work. NASA’s software-engineering guidance emphasizes defining and documenting acceptance criteria and conditions, including suitable ranges, performance, reliability, compatibility, data, and other agreed measures when relevant.［2］

Write criteria from the outside in. Prefer observable outcomes, messages, state transitions, exported records, or measurable tolerances over internal classes, database rows, or chosen libraries.

Use a plain checklist first:

Criterion ID	Situation	Observable outcome	Evidence source	Owner
AC-01	valid submission	user receives a unique reference and clear next step	E-014	product owner
AC-02	duplicate submission	user is warned without losing entered data	E-021	product owner
AC-03	processing unavailable	user receives a recoverable failure path	operational policy P-03	service owner

Avoid criteria such as “build the endpoint,” “use a modal,” or “write unit tests.” Those are implementation or delivery tasks, not user-observable acceptance outcomes.

Which edge cases should acceptance criteria cover?

Ask AI to challenge the normal path using explicit categories:

Boundary: empty, minimum, maximum, expired, duplicate, or unusual-but-valid input.
Failure: unavailable dependency, timeout, rejected request, partial completion, or retry.
Permission: signed out, wrong role, changed ownership, or revoked access.
Accessibility: keyboard operation, focus, status announcement, error recovery, and nonvisual understanding.
Privacy: data minimization, visibility, retention, export, and deletion boundaries.
Security: unauthorized actions, unsafe input, replay, rate limits, and audit needs where applicable.
Operations: monitoring, support handoff, rollback, and behavior during degraded service.

Not every story needs every category, but each category should receive an explicit “covered” or “not applicable” decision. Ask domain owners to review areas where the team lacks authority.

NIST’s generative-AI profile warns that models can produce confident false content and emphasizes evaluation, source verification, human oversight, and safe handling of errors.［5］ Treat an AI-generated criterion as a candidate until the responsible team validates its evidence and feasibility.

When should you use Given, When, Then?

Use Given/When/Then when concrete examples improve shared understanding. Cucumber describes Given as initial context, When as an event or action, and Then as an expected observable outcome. It specifically recommends outcomes visible to the user or external system rather than implementation details buried inside the system.［3］

Example:

Given a signed-in applicant has completed all required fields When the applicant submits once Then the service shows a unique reference and the next expected step

Add separate examples for duplicate submission, lost connectivity, authorization changes, and invalid data instead of packing many branches into one long scenario. A scenario is an example of a criterion, not automatically the entire criterion set.

How are criteria different from tasks, tests, and Definition of Done?

Artifact	Main question	Scope	Owner
user story	what user outcome and why?	one coherent need	product team
acceptance criteria	what observable conditions make this story acceptable?	story-specific	product and relevant stakeholders
implementation tasks	how will the team build it?	technical work	delivery team
test cases	how will specific behaviors be exercised and compared?	verification coverage	QA and engineering
Definition of Done	what shared quality state applies to an Increment?	product or team-wide	Scrum Team/organization

The Scrum Guide defines the Definition of Done as the formal state of an Increment when it meets the product’s quality measures.［4］ It is broader and more reusable than story-specific acceptance criteria. A story may satisfy its functional criteria but still not meet the Definition of Done because documentation, security review, integration, or another shared quality measure remains incomplete.

Acceptance testing is also distinct from acceptance criteria: the criteria state what must be true, while tests and review activities generate evidence about whether it is true. NASA describes acceptance testing as formal testing used to determine whether the system satisfies its acceptance criteria.［2］

For detailed test design after criteria are approved, use the AI test-generation workflow. For repeatable operational instructions, use creating SOP checklists with AI.

How do you create user stories and acceptance criteria with AI and preserve traceability?

Create a requirement traceability table:

Story/criterion	Evidence IDs	Constraint IDs	Test or review evidence	Decision owner	Status
US-07 / AC-01	E-014	P-03	AT-114	product owner	approved

Every criterion should have a source or an explicit owner decision. Every high-impact constraint should map to one or more criteria. Every criterion should later map to test or review evidence, but do not invent that evidence during drafting.

Run a joint review with product, design, engineering, QA, research, accessibility, security, privacy, legal, or operations owners as relevant. Ask:

Is the user and goal supported by evidence?
Are any criteria actually implementation instructions?
Are normal, boundary, and failure outcomes observable?
Are permission, accessibility, privacy, and security decisions explicit?
Are tolerances and exceptions measurable?
Does each item have an accountable approver?

Use the human-approval workflow for the final decision. AI can prepare the review packet; it cannot approve its own requirements.

Summary

Start with verified evidence, constraints, assumptions, and an accountable owner.
Write stories around the actor’s need and goal, not the requested interface.
Split epics along independently valuable outcomes where possible.
Define observable normal, boundary, failure, permission, accessibility, privacy, and security outcomes.
Use Given/When/Then as optional examples, not as a substitute for thinking.
Trace criteria to evidence and keep human approval separate from generation.

FAQ

Can AI write user stories from meeting notes?

It can draft candidates, but meeting statements are not automatically verified user needs. Separate evidence, stakeholder requests, assumptions, and decisions before drafting.

How many acceptance criteria should a story have?

Use enough to define the meaningful normal, boundary, and failure outcomes without turning the story into a specification dump. If the list becomes large or mixes goals, split the story.

Must user stories use “As a, I want, so that”?

No. The format is useful, but the essential information is the actor, need, and goal. Choose a format the team can review consistently.

Are Given/When/Then criteria required?

No. A clear checklist may be better for many stories. Use Given/When/Then when concrete scenarios clarify context, event, and expected outcome.

Are acceptance criteria the same as test cases?

No. Criteria define what must be true for acceptance. Test cases describe specific inputs, actions, environments, and comparisons used to gather evidence.

Is Definition of Done part of every story?

The shared Definition of Done applies to the Increment or product quality state, while acceptance criteria are specific to a story. Both may need to be satisfied before work is complete.

Can AI approve requirements if all criteria are measurable?

No. Measurability does not establish user value, policy authority, feasibility, safety, or organizational approval. The accountable people must decide.

Disclaimer: AI-generated stories and criteria are drafts. They do not replace authorized product, engineering, accessibility, security, privacy, legal, or operational approval.

Sources:

GOV.UK Service Manual — Writing user stories — https://www.gov.uk/service-manual/agile-delivery/writing-user-stories
NASA Software Engineering Handbook — SWE-034 Acceptance Criteria — https://swehb.nasa.gov/spaces/7150/pages/16450634/SWE-034%2B-%2BAcceptance%2BCriteria
Cucumber — Gherkin Reference — https://cucumber.io/docs/gherkin/reference/
Scrum Guides — The Scrum Guide — https://scrumguides.org/scrum-guide.html
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

Sources checked 30 August 2026.

Related Articles:

How to Create User Stories and Acceptance Criteria with AI