A vague user story used to cost you a five-minute conversation at standup. Now it costs you 400 lines of confidently wrong code.
That is the whole reason this old agile checklist suddenly matters again. If you build with Lovable, Bolt, or Cursor, your user stories are the closest thing to a contract your AI pair has, and it will honour every gap in them literally.
Why most user stories fail before anyone writes code
A user story is a short description of a feature from the point of view of the person who wants it, usually written as "As a [role], I want [capability], so that [benefit]."
Most of them fail one of three ways. They describe a solution instead of a need ("add a dropdown"). They bundle several features into one card ("users can manage their account"). Or they leave out the condition that would make them checkable ("the page should load fast").
The symptom is the same in all three cases: the builder fills the gap with an assumption. The difference now is what happens next. A human teammate surfaces the mismatch at standup, usually as a slightly annoyed question. An AI tool ships the assumption immediately, styled and plausible and indistinguishable from the thing you meant.
Consider Priya, a solo PM building booking software for physiotherapy clinics. Her backlog contains this:
Bad: "As a user, I want a better dashboard, so that I can see my stuff."
Every word defers a decision. Which user? Better than what? Pasted into Bolt, it cheerfully generates a dashboard: a generic grid with invented revenue charts. The tool did not fail. The story did.
This is the amplification problem from what vibe coding actually is. AI tools scale input quality in both directions. The fix is not longer stories. It is stories that pass six tests.
The INVEST criteria, letter by letter
INVEST is a checklist for judging story quality, coined by Bill Wake in his 2003 essay INVEST in Good Stories, and SMART Tasks. The letters stand for Independent, Negotiable, Valuable, Estimable, Small, and Testable.
A story that satisfies all six can be built and verified without a clarifying meeting. That is also, not coincidentally, what makes it work as an AI prompt.
Here is each letter in practice, with Marco, an indie hacker building a recipe app in Cursor.
I is for independent
The story should not secretly depend on unbuilt work. Dependency chains stall sprints, and they badly confuse AI tools, which cannot see your backlog.
Bad: "As a home cook, I want to see comments on my recipe, so that I feel connected." (Silently depends on accounts, recipe pages, and a comment-posting story that does not exist.)
Good: "As a home cook, I want to post a comment on any published recipe, so that I can ask the author questions. Comments require a logged-in account and appear immediately under the recipe."
N is for negotiable
The story is a placeholder for a conversation, not a spec carved in stone. State the what, leave the how open.
Bad: "As a user, I want a React modal with a Formik form and a Postgres upsert, so that I can edit my profile." (An implementation ticket wearing a story costume.)
Good: "As a home cook, I want to update my display name and avatar, so that other cooks recognise me. Changes take effect everywhere my name appears."
V is for valuable
If you cannot finish the "so that" clause honestly, it is a task, not a story. "As a developer, I want to refactor the auth module" is real work. It belongs in a tech-debt lane, not disguised as user value.
E is for estimable
A builder, human or otherwise, has to be able to size it. Stories become unestimable when they hide research ("integrate with whatever calendar APIs exist") or unbounded scope ("support all file types"). If you cannot estimate it, split out a timeboxed spike and estimate that instead.
S is for small
Mike Cohn's guideline at Mountain Goat Software is that a story should fit in a few days. For AI-assisted builds I would tighten that: one story, one focused generation session. If the tool has to touch twelve files across four domains, you have an epic in disguise. Slicing tactics are below.
T is for testable
Every story needs a condition you can check with a yes or a no. "Search should be fast" is a wish. "Search results render within 1 second for a 10,000-recipe catalogue" is a test.
The rewrite gallery
The fastest way to internalise INVEST is to watch weak stories get fixed. The move is the same every time: name a specific persona instead of "user," replace the proposed solution with the underlying need, add the boundary conditions, and finish with something that could fail.
These six come from three builders. Priya, the solo PM above. Marco, the indie hacker with the recipe app. And Dana, a technical founder building invoicing software for freelance translators.
1. Priya, scheduling
Bad: "As a user, I want to book appointments easily." (No persona, no scope, and "easily" cannot be tested.)
Good: "As a returning patient, I want to book a follow-up from my last practitioner's available slots, so that I don't repeat my intake details. Slots reflect calendar changes within 1 minute; double-booking is impossible."
2. Priya, notifications
Bad: "As a user, I want notifications so that I don't miss things." (Which events? Which channel?)
Good: "As a clinic owner, I want an email when a patient cancels within 24 hours of their appointment, so that I can offer the slot to the waitlist. It arrives within 5 minutes with a one-click notify-waitlist link."
3. Marco, search
Bad: "As a user, I want to search recipes." (By what? What does the empty state look like?)
Good: "As a home cook, I want to search recipes by ingredient, so that I can use what's in my fridge. Matching is case-insensitive, results show within 1 second, and an empty result suggests removing the rarest ingredient."
4. Dana, invoicing
Bad: "As a user, I want to manage invoices." (An epic pretending to be a story. Create? Send? Void? Export?)
Good: "As a freelance translator, I want to duplicate a past invoice with a new number and date, so that repeat clients take 30 seconds to bill. Line items copy over, the number auto-increments, and the copy opens in draft state."
5. Dana, payments
Bad: "As a user, I want Stripe integration." (Implementation, not need, and unestimable.)
Good: "As a freelance translator, I want each sent invoice to include a payment link, so that clients pay without a bank transfer. Successful payment marks the invoice paid and emails me a receipt within 2 minutes."
6. Marco, onboarding
Bad: "As a new user, I want a smooth onboarding experience." ("Smooth" cannot fail a test, so it cannot pass one.)
Good: "As a first-time visitor, I want to save my first recipe before creating an account, so that I see value before committing. The save persists through signup."
Every good version has a named persona, one capability, an honest benefit, and a condition that could fail. That last part is the one AI tools need most. A story that cannot fail a test lets the tool invent its own definition of done, and it will.
How to slice stories that are too big
Story slicing means splitting a large story into smaller ones that each still deliver something a user can see. The metaphor worth keeping is cutting a cake vertically, through all the layers, rather than horizontally by tier.
"Build the schema," then "build the API," then "build the UI" is horizontal slicing. Nothing is usable until everything ships, and you find out on the last slice whether the first one was right. Vertical slicing gives you thin end-to-end paths instead, each one complete and testable on its own. Atlassian's guide to user stories makes the same point: stories are units of deliverable work, not units of architecture.
Four patterns cover most oversized stories.
By workflow step. Dana's "manage invoices" epic becomes: create a draft, then send by email, then record a manual payment, then void. Each ships alone.
By business rule. "Calculate booking fees" becomes: flat fee, then discounted follow-up fee, then first-visit waiver. Ship the flat fee and the app is usable immediately.
By data variation. Marco's "import recipes" becomes: from a pasted URL, then from a photo, then from a PDF. The URL slice alone is shippable.
By capability level. "Search" becomes: exact match, then multi-ingredient match, then typo-tolerant match. Version one is honest and small.
A quick smell test: if the title contains "manage," "handle," "support," or "system," it is probably an epic. Slice until each story can be generated, reviewed, and merged in one sitting.
Your stories are prompts
When you build with AI tools, a story stops being a conversation starter and becomes a specification that gets implemented literally, gaps included.
Humans fill ambiguity with context and questions. Language models fill it with statistically plausible guesses. Which means INVEST, written in 2003 for human teams, is arguably more valuable now than it was then. Independent stories stop the tool hallucinating dependencies. Negotiable stories let it pick something idiomatic for your stack. Testable stories give it a definition of done it cannot quietly redefine.
The handoff that makes this work is pairing every story with explicit acceptance criteria before generation starts. Priya's cancellation story from example 2 gets:
Acceptance criteria:
- Given an appointment starting in <24h, when the patient
cancels, then the owner gets an email within 5 minutes.
- Given an appointment starting in >24h, when the patient
cancels, then no email, it goes to the daily digest.
- Given the email is sent, then it contains patient name,
slot time, and a one-click "notify waitlist" link.
Three lines that eliminate the three likeliest misreadings: emailing on every cancellation, dropping the time threshold, and inventing the email's contents. Writing criteria at that precision is its own skill, covered in what LLMs skip in acceptance criteria.
The pre-build checklist
Ten checks, applied to every story before it enters a sprint or a prompt. Six are INVEST; four are practical additions that catch what INVEST alone misses.
The bar for passing is concrete: a mid-level developer or a competent AI tool could build it without asking a single clarifying question. "Sounds reasonable in refinement" is not the bar.
- Named persona. A specific role in a specific situation, never "user."
- One capability. No "and," no "manage," no bundled verbs.
- Honest benefit. The "so that" would survive being read aloud to a customer.
- Independent. Names its preconditions and depends on nothing unbuilt.
- Negotiable. Describes the need, not the implementation.
- Estimable. Sizable without a research phase.
- Small. Fits one focused session.
- Testable. At least one condition that could fail.
- Acceptance criteria. Two to five Given/When/Then statements: happy path, one edge, one error.
- Edge states. Empty, loading, error, and permission-denied behaviour either stated or explicitly deferred.
FAQ
What is the correct format for a user story?
The standard template is "As a [role], I want [capability], so that [benefit]." The format matters less than the content. "As a user, I want the feature, so that it works" satisfies the template and misses the point entirely.
What does INVEST stand for in agile?
Independent, Negotiable, Valuable, Estimable, Small, and Testable. Six criteria for judging story quality, coined by Bill Wake in 2003. A story meeting all six can be built and verified without clarifying meetings, which is also what makes it an effective AI prompt.
How long should a user story be?
The sentence itself is one or two lines. With acceptance criteria and edge-case notes, a well-formed story runs 5 to 15 lines. If it needs more, it is usually an epic that wants slicing.
What is the difference between a user story and acceptance criteria?
The story states who wants what and why. The criteria state the checkable conditions that prove it is done. One story typically carries two to five criteria, often in Given/When/Then form. The story is the contract's intent; the criteria are its enforceable clauses.
Can AI generate user stories for me?
Yes, and the structure will usually be fine. Treat the output as a first draft: models are good at format and edge-case prompting, but only you know your users and constraints. The critique loop covers how to pressure-test generated stories properly.
How many user stories should be in a sprint?
There is no universal number, since it depends on story size and capacity. The better question is whether each story is small enough to finish in a few days. A solo builder working with AI tools might get through 5 to 10 well-sliced stories a week. Fewer, larger stories usually means slicing is overdue.
Are user stories still relevant when building with Cursor or Lovable?
More than before. These tools implement exactly what you specify and guess at everything you do not. A tight story with acceptance criteria is the highest-leverage input you can give them, because it converts ambiguity, the main cause of wrong output, into checkable requirements.
What is story slicing?
Splitting an oversized story into smaller ones that each still deliver end-to-end user value, cutting vertically through the stack rather than by technical layer. Common patterns: slice by workflow step, business rule, data variation, or capability level.
If you would rather edit a draft than start from a blank page, the User Story Generator turns a plain-English feature description into INVEST-checked stories with paired acceptance criteria. Free, no signup, and the checklist above still applies to whatever comes back.
