Asking an LLM for user stories is not hard. You will get a tidy list back in about eight seconds, and roughly a third of it will be usable.
This post is about the other two thirds. Specifically, it is about the second pass, which is the part almost everyone skips and the part that decides whether the output is worth anything.
If you need the fundamentals first, what actually makes a story buildable, the INVEST guide covers that ground properly with eight rewritten examples. I am going to assume you know what a good story looks like and focus on how to get a model to produce them reliably.
Why the first draft is always mediocre
An LLM generating user stories is doing pattern completion against a decade of public backlogs, and most public backlogs are bad. The training data is full of "As a user, I want to manage my settings," so that is the shape it reaches for.
There is a second, less obvious problem. The model has no idea what it does not know about your product. A human PM handed a vague brief asks a question. A model handed a vague brief produces confident output at the same fluency regardless of how much context it actually had. You cannot tell from the tone whether it understood you.
Both problems are fixable, but not by writing a better first prompt. They are fixable by making the model attack its own output.
Step 1: a first draft worth critiquing
The goal of the first prompt is not perfection. It is coverage, in a format you can systematically pick apart.
Generate user stories for this feature.
Feature: <DESCRIPTION>
Product context: <ONE PARAGRAPH: what the product is, who uses it>
Personas that exist: <NAMES AND ROLES, or "none defined yet">
Format: "As <named persona>, I want <capability>, so that <benefit>."
For each story return:
- persona (must be from the list above, never "the user")
- the story sentence
- size: S / M / L
- scope: frontend / backend / fullstack
- assumptions you had to make to write this story
Rules:
- 3 to 6 stories. Do not pad to hit a number.
- One capability per story. If you need "and", split it.
- Every story needs a condition that could fail.
Output as a JSON array.
The field doing the most work there is assumptions. Models will happily invent scope, and normally that invention is invisible because it arrives in the same confident register as everything else. Asking for assumptions explicitly drags it into the open, where you can read a line like "assumed users can belong to multiple teams" and catch a decision you never made.
The second most useful constraint is "do not pad to hit a number." Ask for ten stories and you will get ten, including four that are the same story wearing different verbs.
Step 2: the critique pass
This is the step that matters. Take the output from step one and hand it back with a hostile rubric.
Here are user stories you generated:
<PASTE STEP 1 OUTPUT>
Review them as a skeptical engineering lead who has to build these.
For each story, answer:
1. Could I build this without asking a single clarifying question?
If no, what exactly is missing?
2. Is this actually one capability, or several bundled?
3. Name a specific way this story could be built technically
correctly and still be wrong.
4. What edge case does this story silently assume away?
5. Is the "so that" clause a real user benefit, or a restatement
of the capability?
Be harsh. Stories that pass everything are suspicious.
Output: for each story, a verdict of KEEP / REWRITE / SPLIT / CUT,
with a one-line reason.
Question 3 is the one that earns its keep. "Technically correct and still wrong" is the exact failure mode of AI-assisted building, and asking the model to predict it surfaces gaps that a checklist review misses entirely.
A word on why this works at all, since asking a model to grade itself sounds like it should be useless. It partly is: models rate their own output generously when you ask "is this good?" They perform much better when you give them a specific adversarial role and concrete questions, because that is a different task from self-assessment. You are not asking it to score. You are asking it to generate a new thing, namely objections, and generating objections is something it is genuinely competent at.
If you want a stronger version, run the critique in a different model from the one that wrote the stories. Claude reviewing GPT output, or the reverse. The failure modes do not fully overlap, and you catch more.
Step 3: rewrite only what failed
Feed back only the REWRITE and SPLIT verdicts, with the reasons attached. Do not regenerate the whole set, because you will lose the stories that were already fine and get a new batch with new problems.
Rewrite only these stories, addressing the specific critique attached:
<PASTE THE FAILED STORIES + THEIR VERDICTS>
Keep the same format. Do not touch the stories that passed.
For splits, produce the separate stories and note any ordering dependency.
Two or three loops is usually where it stops improving. Past that you are polishing, and the remaining problems are ones the model cannot see because they require knowing your users.
Failure signatures specific to AI-written stories
These are the patterns I look for first, because they are more common in generated stories than in human-written ones.
The persona is decoration. The story says "As Priya, a clinic owner" but nothing downstream of the comma would change if it said "As Marco, a home cook." The persona was inserted because the format demanded one. Test: swap the persona name for a completely different one. If the story still reads fine, the persona is not load-bearing.
Benefit restates capability. "As a user, I want to export invoices, so that I can export my invoices." Extremely common, and easy to miss because it scans as complete.
Invented scope. Stories referencing features you never described. Usually arrives in clusters, because once the model decides your app has teams, it writes four team stories. The assumptions field catches most of these.
Uniform size. Every story comes back M. Real backlogs are lumpy. Uniform sizing means the model is pattern-matching the format rather than reasoning about the work.
Suspicious completeness. Every story has exactly three acceptance criteria, one happy path, one edge, one failure. Real features are not that symmetrical. Some have one obvious path and eleven ways to fail.
No dependencies. Generated sets tend to present every story as independent, because Independent is one of the INVEST letters and the model is optimising for the rubric. Actual features have ordering constraints. If nothing depends on anything, nobody thought about sequence.
Where AI genuinely beats a human first draft
I do not want this to read as "the model is bad and you must supervise it." There are things it does better than most people writing stories by hand.
It is more thorough about unglamorous paths, once you ask. A human writing stories at 4pm skips the permission-denied case. A model prompted for it will not.
It does not get bored. Story fourteen gets the same attention as story two, which is not true of any human I have worked with, including me.
And it is a much better sparring partner than a blank page. The critique loop above works in the other direction too: write your own stories, then ask the model to attack them. Same rubric, and it will find things.
When to stop
Stop when the remaining objections require information the model does not have. "Would clinic owners actually want this?" is not a question another loop will answer. That is a question for a person who owns a clinic.
The loop is for structural quality, which it handles well. It cannot validate that you are building the right thing, and running more iterations will not change that.
Related reading
- How to write user stories that pass INVEST, the fundamentals, with a rewrite gallery and slicing tactics.
- AI acceptance criteria, the same critique discipline applied to the layer below stories.
- How to generate an app spec from a prompt, where story generation sits in the wider pipeline.
If you want a first draft to run this loop against, the User Story Generator produces INVEST-format stories with paired acceptance criteria from a plain-English description. Free, no signup. It gives you step one; the critique pass is still yours.
Sources and further reading
- Mike Cohn, User Stories Applied: origin of the INVEST criteria.
- Bill Wake, INVEST in Good Stories, and SMART Tasks: the 2003 essay that coined it.
- Atlassian, User Stories: Examples and Template: the canonical story structure.
- Cucumber, Gherkin Reference: Given/When/Then syntax.
