User Stories and Acceptance Criteria With AI Drafts You Can Defend

What a story and its acceptance criteria are

A user story is a short statement of a need from the point of view of the person who has it. The Agile Alliance describes the common template as "As a... I want to... So that...", which captures who wants to do something, what they want to do, and why. It also makes a point that is easy to forget: the template works as a set of training wheels that prompts a team to think about the user and their objective, and the detail usually comes out later in conversation. A story is a placeholder for a conversation, not a specification.

Acceptance criteria are the conditions that must hold for the story to count as done. This is where the detail lives, and where an AI draft is most likely to go wrong. A story such as "As a customer, I want to track my order so that I know when it will arrive" is easy to write and easy for a model to generate. The hard part is saying, in a way that a tester who has never met you can check, what "track" must do on a Monday morning when the courier has not scanned the parcel.

This guide covers what good looks like, how to ask AI for drafts that give you a fair start, and how to review them so that you can defend every line to a developer, a tester and the person who owns the rule.

INVEST: a quick screen for the story

INVEST is a mnemonic from Bill Wake's 2003 article "INVEST in Good Stories, and SMART Tasks". It gives six properties to check.

• 6properties in INVEST
• 5review checks for an AI draft

Wake notes that writing a story implies the team understands it well enough to test it. That makes Testable the property that connects the story to its criteria. When you review AI output, check Valuable and Testable first. A fluent story with a hollow "so that" and untestable criteria will pass a quick glance and fail later, at greater cost.

The Agile Alliance also warns that novice teams often apply the template too rigidly, and that looser wording can communicate intent equally well. Do not spend a review cycle arguing about "I want to" versus "I need to". Spend it on whether the criteria can fail.

Acceptance criteria that can fail

Given/When/Then is the most common way to write criteria. The Agile Alliance describes it as a format meant to guide acceptance tests for a story: some starting context, an action, and the results that should then be observable. The Cucumber documentation, which defines the Gherkin language used by many test tools, is more precise about the purpose of each part.

• Given puts the system into a known state before anything happens. Cucumber advises keeping user interaction out of it. It is the scene, not the action.
• When is the event or action: a person doing something, or another system triggering something.
• Then is the expected outcome, and Cucumber says it should be observable from outside the system, not a hidden internal change such as a database record.

A fictional illustration. Suppose a retailer's policy is that an order of at least a stated value qualifies for free delivery. A weak AI-drafted criterion would be: "Large orders get free delivery." A criterion that can fail would be:

Given a basket containing items to the value of the free-delivery threshold, when the customer reaches the delivery step, then the delivery charge shown is zero and the order summary says "Free delivery".

Notice the pieces. There is a precondition (the basket), a trigger (reaching the delivery step), an observable outcome (the charge on the screen), and a threshold that must come from the policy document, not from the writer's sense of what feels large.

Gherkin also gives you tools worth borrowing in plain documents. And and But continue a step without repeating the keyword. A Background holds Given steps that every scenario in a group shares. A Scenario Outline runs the same scenario with different values listed in an Examples table, which is a compact way to show many cases without repeating the text.

Rules and examples

Cucumber's reference also has a Rule keyword, described as representing one business rule that should be implemented, with the scenarios that illustrate it grouped beneath it. That idea is useful even if you never write Gherkin. Keep two things apart:

• The rule is the general statement, owned by the business: "Orders at or above the threshold qualify for free delivery."
• The examples are specific cases that show the rule at work, including the awkward ones.

AI drafts tend to produce one happy-path example per story and call it done. For each rule, look for at least these examples:

1. A typical case where the rule applies.
2. A typical case where it does not.
3. The cases at the edge: just below, exactly on and just above the threshold. These are what testers call boundary values, and they expose the question that the words "over" and "at least" quietly hide.
4. An invalid or unusual input: a negative quantity, an empty basket, a missing field.
5. A case where two rules meet: a discount code and the free-delivery threshold, say.

If an example reveals that nobody has decided which side of the boundary the exact threshold falls on, you have found a question for the rule's owner, which is a better outcome than a developer guessing.

Traceability: why this line exists

An acceptance criterion is only defensible if you can say where it came from. ISO/IEC/IEEE 29148, the international standard for requirements engineering, defines requirements traceability as the identification and documentation of the derivation path upward and the flow-down path downward of requirements. In plain words: for any criterion you can go back up to the need or rule that justifies it, and down to the tests and work that realise it.

For stories, a lightweight version works well. Give each story and each criterion three fields:

• Source: the transcript line, the policy section or the ticket that supports it, with version.
• Owner: the person who can confirm the rule it states.
• Status: confirmed, or waiting on a named question.

The same standard defines requirements validation as confirming that the requirements define the right system as the stakeholders intend, and verification as confirming that they are well formed. A review checklist for AI drafts mixes both. Spotting a vague word is verification. Confirming with the owner that the threshold is right is validation, and no tool can do it for you. Our guide on how AI changes requirements discovery covers how to collect sources in a form that stories can cite.

How to prompt for a draft you can use

Models are good at following a clear brief. These habits follow guidance that model providers publish, and they apply to any tool.

1. 1GatherCollect the approved sources: transcript lines, policy text, process notes
2. 2PromptSupply the sources with labels and ask for drafts, questions and assumptions
3. 3DraftThe model proposes stories and criteria; nothing is accepted yet
4. 4ReviewRun the five checks below against each line
5. 5ConfirmTake rules and thresholds to their owners
6. 6RecordKeep source, owner and status with each story

Give it sources, and label them. Anthropic's prompting guidance advises putting long documents at the top of the prompt and wrapping each one with its source information, which makes it easier for the model to refer back to the right one. Give each source an identifier so that the model can cite it.

Say what to do when the sources are silent. Anthropic's documentation on reducing hallucinations recommends giving the model explicit permission to say it does not know. Use that: "If the sources do not state a value, write NOT PROVIDED and add it to the question list." Without it, a model will often supply a plausible number.

Ask for separate outputs. Request the stories, a list of assumptions it made, and a list of questions for the business. Mixing them hides the guesses inside the stories.

Ask for a source against each criterion. The same documentation suggests asking for a supporting quote for each claim and retracting any claim that has none. Applied to criteria, that means a source ID next to every threshold and rule.

Show it your format. Anthropic notes that a few well-chosen examples are one of the most reliable ways to steer format and tone. Paste one story that your team already accepted as an example, with any real names removed.

Keep personal data out. Use synthetic examples ("a customer in a small town reports a late delivery"), never real customers. If you are unsure what your tools may receive, read our guide to using AI safely at work.

A prompt that applies all of this might read:

You are helping a business analyst. Using only the labelled sources below, draft user stories for the feature described. For each story give: the story in the form who, what, why; acceptance criteria in Given/When/Then form; and a source ID for every rule, number and exception. Do not invent rules or thresholds. If a source does not state something needed, write NOT PROVIDED and add a question for the business to a separate list. List any assumptions you made separately. Do not include any real names or personal data.

Anthropic's documentation is clear that these techniques significantly reduce but do not eliminate made-up content. The prompt improves the draft. It does not replace the review.

The review checklist for AI-drafted stories

Run these five checks on every story. They take minutes once you have the habit, and they are where a business analyst earns the right to say "I stand behind this".

1. Invented requirements

Is each rule, number and exception in an approved source? Highlight every number and every "always", "never" and "only". For each, find the line that supports it. NIST's Generative AI Profile describes confabulation as confidently stated but false content and notes that a model can also generate citations that appear to justify an answer, so check that the cited source really says what the draft claims. If nothing supports it, remove it or move it to the question list. A rule you keep because it sounds sensible is still an invented rule, and now it has your name on it.

2. Missing negative and boundary cases

Count the examples against the rule. Is there a case where the rule does not apply? Is each threshold tested on both sides and on the line itself? What happens with missing, invalid or duplicate input? What happens when the dependent system is unavailable? Add them, or ask the owner.

3. Solution-led wording

Does the story or criterion name a design: a button, a pop-up, a chatbot, a database table? Per Wake, a story should be Negotiable and capture the essence rather than the details. Rewrite so the criterion describes what a person can achieve or see, and leave the how to the team. "The customer clicks the Track button" becomes "the customer can see the current delivery status for an order".

4. Vague quality words

Search the draft for words that cannot fail. Typical offenders include quickly, promptly, easy, user-friendly, intuitive, secure, appropriate, regularly, large, small and "as required". Each needs a measurable value from a source ("within 2 seconds at the 95th percentile" is an example of the shape, not a number to copy), or it becomes an open question or a separate non-functional requirement. Vague words also hide a missing actor: "the user" or "someone" should be a named role, or "the system" when the trigger is an event such as a time limit passing.

5. Untraceable items

Does every story and criterion have a source, an owner and a status? Is there any text about who approved it, and does it name a person? An AI tool or "the team" is not an approver. Look too for personal data that has slipped into examples, such as real names, phone numbers or identity numbers, and replace them with synthetic ones.

A worked repair

Suppose an AI produces this for a retailer's returns feature:

As a user, I want to return items easily so that I am happy. The system should process returns quickly and notify the customer. Returns older than 30 days are rejected.

Running the checks:

• Invented: "30 days" is not in any source the team supplied. It is moved to the question list for the returns-policy owner, and the criterion is marked as waiting.
• Missing cases: nothing covers a return exactly on the last day, a partly returned order, or an item the policy does not allow back.
• Solution-led: nothing here, but "notify" is silent on the channel; that is a question, not an assumption.
• Vague: "easily", "quickly" and "happy" cannot fail. "Easily" becomes either a usability requirement with a measure or is dropped. "Quickly" needs a time from a source.
• Untraceable: there is no source or owner, and "user" is not a role.

The repaired story names the role (the customer), states a real need (to return an item and get a refund without contacting support), and carries criteria with Given/When/Then, a boundary example for the last permitted day, a source ID beside each rule, and a list of three open questions with owners. It is shorter on certainty and longer on honesty, and that is the version you can defend.

How we practise this

In our AI-Augmented Business Analysis course, the story and acceptance-criteria week is built around reviewing drafts that look fine and are not: finding what is invented, untestable or untraceable, and sending the right questions to the right owner. Later weeks extend the same habit to decision tables, data, non-functional requirements and change impact.

Sources and further reading

• Wake, B. (2003), INVEST in Good Stories, and SMART Tasks
• Agile Alliance, User Story Template for Agile
• Agile Alliance, What is "Given - When - Then"?
• Cucumber, Gherkin Reference
• ISO/IEC/IEEE (2018), 29148:2018 Systems and software engineering, Life cycle processes, Requirements engineering
• ISO/IEC/IEEE (2018), 29148:2018 publisher preview, section 3 definitions of traceability, validation and verification
• NIST (2024), AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• Anthropic, Reduce hallucinations and Prompting best practices