How to Prompt AI to Write User Stories

Ask an AI tool to "write a user story for data export" and you'll get something like this: "As a user, I want to export my data so that I can use it elsewhere." Technically a user story. Useless as a ticket. No acceptance criteria, no edge cases, nothing a developer or QA person could actually build or test against.

Here's the same request handled properly. Feature request: "add a way for users to export their data." Better prompt, with constraints and a required output format. Result: three scoped stories, each with acceptance criteria a developer could estimate and QA could verify. That gap between the two outputs is entirely about how to prompt AI to write user stories, not which model you use.

Why the lazy prompt fails

Most people prompt like they're talking to a search engine. One sentence, no context, no format. The AI has no product context, no idea who the user is, no constraints to work within, so it defaults to the most generic template it has seen a million times in training data.

Bad prompt: "Write a user story for exporting user data."

What you get back:

• As a user, I want to export my data so that I can access it outside the app.

• Acceptance criteria: The user can export their data. The export works correctly. The user receives their data in a usable format.

That's not acceptance criteria. That's the feature request restated three times with different verbs. Nobody can build against "the export works correctly." Which format? Which data? What happens with a 2-million-row account? None of that is answered because none of it was asked.

This is the core failure mode when people try to get AI generated user stories: they treat the AI like a mind reader instead of giving it the same inputs a product manager would need before writing the ticket themselves.

A prompt template that actually works

The fix isn't a magic phrase. It's giving the model the same inputs you'd want from a junior PM: the actor, the goal, the constraints, and an explicit request for the parts people forget.

Better prompt:

"Act as a senior product manager. Take this feature request and break it into 2-4 separate user stories, each scoped to one piece of functionality: [feature request]. For each story, use the format 'As a [user type], I want [goal] so that [benefit].' Then add acceptance criteria written as Given/When/Then statements. Include at least one edge case or failure scenario per story. Flag any non-functional requirements (performance, security, data limits). End each story with a one-line definition of done. Ask me clarifying questions first if the request is ambiguous."

This is the as a user I want prompt template that separates usable tickets from filler, because it front-loads the four things generic prompts skip: story splitting, structured acceptance criteria, edge cases, and non-functional requirements. The "ask clarifying questions first" line matters more than people expect. A model that asks what export formats you support before writing stories is doing PM work. A model that guesses is doing improv.

From vague ticket to three scoped stories

Feature request as it might arrive in a backlog: "add a way for users to export their data."

Run it through the template above and a well-prompted AI should split it like this.

Story 1: Export request initiation

• As an account owner, I want to request an export of my account data so that I can retain a copy outside the platform.

• Given I am logged in and on the account settings page, when I click "Export my data," then I receive a confirmation that the export has started and an estimated completion time.

• Given I already have an export in progress, when I click "Export my data" again, then the system blocks the duplicate request and shows the status of the existing export.

• Edge case: account has over 500,000 records; the system queues the job asynchronously instead of generating it inline and timing out.

• Non-functional requirement: export generation must not degrade page load times for other users on shared infrastructure.

• Definition of done: request triggers a background job, user sees status in the UI, and a duplicate request is blocked.

Story 2: Export format and delivery

• As an account owner, I want to receive my exported data as a downloadable CSV or JSON file so that I can import it into another tool.

• Given my export is complete, when I open the notification email, then I see a secure download link valid for 72 hours.

• Given the download link has expired, when I click it, then I see a clear expiration message with a button to regenerate the export.

• Edge case: user's email bounces or is undeliverable; the export still appears as "ready to download" inside the app itself, not only via email.

• Non-functional requirement: download link must be scoped to the requesting account only and expire automatically, no permanent public URLs.

• Definition of done: file downloads successfully in both formats, link expires on schedule, and in-app fallback exists if email fails.

Story 3: Export scope and privacy controls

• As an account owner, I want to choose which data categories are included in my export so that I don't pull data I don't need or shouldn't share.

• Given I start an export, when I reach the export screen, then I can select from checkboxes (profile data, activity history, billing history, etc.) before generating the file.

• Given I am a team member without admin rights, when I request an export, then I only see data categories I'm permitted to access, not the full account.

• Edge case: user deselects every category; the "generate export" button stays disabled with a message explaining why.

• Non-functional requirement: exported files must exclude other users' PII even when the requester has admin access to a shared workspace.

• Definition of done: category selection persists per request, permission scoping is enforced server-side (not just hidden in the UI), and empty selections are blocked.

Compare that against the one-liner from the lazy prompt. Same underlying feature, completely different level of usefulness. This is what an ai generated user stories example should look like when the prompt does its job: three independently shippable pieces of work instead of one story trying to cover login state, file format, delivery, and permissions all at once.

What good acceptance criteria actually look like

The Given/When/Then structure isn't decoration. It forces three separate answers: the starting state, the trigger, and the observable result. Ask AI for "acceptance criteria" without that structure and you'll get vague verbs like "works correctly" or "is user-friendly," neither of which a QA engineer can turn into a test case.

When you're specifically after user story acceptance criteria ai output that holds up in a sprint planning meeting, name the format in the prompt. Don't assume the model knows you want Given/When/Then instead of a bullet list of adjectives. The INVEST criteria from Agile Alliance (independent, negotiable, valuable, estimable, small, testable) is a useful gut check afterward: read each generated story and ask if it would still make sense split off from the others and handed to one developer alone. If it wouldn't, the split was wrong, not just the wording.

Edge cases and non-functional requirements to always request

AI defaults to the happy path unless told otherwise. Bake these into every prompt, not just for exports:

• What happens with zero data, or the maximum realistic amount of data?

• What happens if the action is triggered twice, or interrupted midway?

• Who is explicitly not allowed to do this, and what should they see instead?

• What are the performance, security, or compliance constraints (data retention, PII, rate limits)?

• What does "done" mean in one sentence, separate from the acceptance criteria?

That last one, a definition of done, is easy to skip and it's often what separates a story that's actually shippable from one that technically passes every listed criterion but still isn't ready for release (missing tests, missing docs, missing rollback plan).

Putting it into your workflow

Treat the prompt like a template you reuse, not something you retype from memory each time. Keep the actor, goal, constraints, and required output format fixed, and only swap in the feature request. Review the output the way you'd review a draft from a new hire: check the split makes sense, check the edge cases match your actual product (not generic SaaS edge cases), and check the acceptance criteria reference real UI elements and real permission models, not placeholders. The Scrum Guide's description of a user story as a placeholder for a conversation still applies. AI can draft the placeholder fast. It can't have the conversation about your actual permission model or your actual data volumes unless you tell it what that conversation would have covered.

This template builds on the basics in our prompt engineering fundamentals guide. Once stories are drafted, the natural next document is prompting AI to write a product spec, especially for anything that spans more than one story.

If you are running this prompt often, getting consistent AI output every time is worth reading so your stories don't drift in format week to week. And once a story reaches engineering, writing acceptance criteria for an AI coding agent covers the same Given/When/Then discipline from the implementation side.

FAQ

What's the best AI prompt for writing user stories?

Give it the feature request, an explicit output format (actor, goal, benefit, then Given/When/Then acceptance criteria), and instructions to include edge cases, non-functional requirements, and a definition of done. Asking it to pose clarifying questions first improves accuracy further.

How do I get AI to write better acceptance criteria, not just generic ones?

Name the format directly. Ask for Given/When/Then statements tied to specific UI states, not adjectives like "works correctly" or "is intuitive." Generic criteria almost always come from a prompt that never specified a structure.

Should one feature request become one user story or several?

Usually several. A request like "add data export" bundles initiation, delivery, and permissions into one sentence. A good prompt should split these into independently testable stories rather than one story trying to cover everything.

Can AI replace a product manager for writing user stories?

No, but it can replace the blank-page problem. It drafts structure fast; a PM still needs to confirm the edge cases match the real product, the permission model is accurate, and the acceptance criteria reflect what "done" actually means for that team.

What's a definition of done and why does it matter for AI-written stories?

It's a one-line statement of what must be true for the story to count as complete, separate from the acceptance criteria themselves (tests written, no regressions, documentation updated). AI tends to skip it unless the prompt asks for it explicitly, which leaves stories that pass every listed check but still aren't release-ready.