Using AI to write user stories: prompt, sample draft, fixes
One full pass of writing a user story with AI: the input context, the prompt, an illustrative draft, a table of the PO's fixes and the final story with AC.
Written by Phan Lam Duy Khoi
AI writes useful user stories when you give it enough context, meaning the user, the agreed rules and the scope, and ask it to list questions instead of guessing. The PO still fixes invented rules, out-of-scope features and missing error cases before the team sees it.
Is it fine to use AI to write user stories?
Yes, if you give it enough context and fix the draft before it reaches the team. AI gets the format right very quickly. Where it goes wrong is business rules, scope and error cases. Those live in your head and in the heads of the people who own the business, not in the prompt.
Below is one complete pass on a single example: the input context, the prompt, the AI draft, a table of what the PO fixed, and the final story with acceptance criteria. The example is a booking feature for a small spa. The spa's name and every rule are made up.
If user stories or acceptance criteria (AC) are new to you, the two articles below start from the beginning.
What input should you prepare before writing the prompt?
Most of the draft's quality is decided here. Anthropic, the company behind Claude, suggests treating the model like a brilliant new employee who knows nothing about how your team works. The more precisely you explain, the closer the result.
For a user story, the input needs five parts: who is struggling, how they cope today, the agreed rules, what is in scope and what is not.
Illustrative example: Huong Buoi is a small spa (a made-up name). This is the context the PO wrote down after talking to the owner:
- Customers book by messaging the spa's Facebook page. The owner replies by hand, misses messages in the evening, and sometimes books two people into the same slot.
- The spa has 3 rooms and 4 therapists. A time is only open when both a room and a therapist are free.
- Opening hours are 9:00 to 20:00. Services last 60 or 90 minutes and must end by closing time. Start times run in 30-minute steps.
- Customers must book at least 2 hours ahead. There is no deposit this time; customers pay at the spa.
- After booking, the customer sees a confirmation screen and the spa receives an email about the new booking.
- Not in scope this time: online payment, choosing a therapist, changing or cancelling bookings on the web.
Look at the second line. It is the rule most likely to be missed, because outsiders assume a free room means a free slot.
What should a user story prompt include?
This prompt works with ChatGPT, Claude or any other tool. It differs from the slicing prompt in the 5 prompts article: it takes an agreed context and asks for the story and its AC in one pass.
You are an experienced Product Owner. Write a user story and acceptance criteria for the feature below. Context: - Who is struggling: [user group, in what situation] - How they cope today: [short description] - Agreed rules: [numbers, limits, conditions] - In scope this time: [list] - Not in scope this time: [list] Instructions: 1. Write one user story as "As a…, I want…, so that…". The "so that" part must say what will change. 2. Write at most 8 acceptance criteria in Given / When / Then. Each has one action and one result that can be checked. 3. Include at least one criterion for an error case. 4. Use only the rules in the context. Do not add numbers, time limits or new features. 5. Where information is missing, list it under "Open questions" instead of guessing.
The last two lines matter most. They tell the AI to ask instead of filling gaps. It will not always comply. Anthropic's own documentation says techniques to reduce made-up content lower it but do not remove it. So you still read the draft closely.
What does the AI draft look like?
Below is an illustrative draft. I wrote it to show mistakes that are common in AI drafts. It is not the output of a specific run with any tool.
- Story: As a user, I want to book a spa appointment online, so that it is more convenient and saves time.
- AC1. Given the customer is on the booking page, When they choose a service, Then the system shows time slots with a free room.
- AC2. Given the customer has chosen a slot, When they enter a name and phone number and tap Book, Then the booking is created and the customer receives an SMS confirmation.
- AC3. Given the customer picks a favourite therapist, When that therapist is busy, Then the system suggests another therapist.
- AC4. Given the customer has a booking, When they cancel more than 24 hours ahead, Then it is cancelled free of charge.
- AC5. The system loads time slots quickly and is easy to use on mobile.
- AC6. The system sends a reminder message 1 hour before the appointment.
- Open question: Do customers need to log in to book?
At a glance it looks fine: right format, Given / When / Then, even an open question. That is exactly why you read it slowly. The draft adds three things that are not in the context, includes two out-of-scope features, and misses several agreed rules.
What did the PO fix, and why?
| AI draft | Problem | Fix |
|---|---|---|
| As a user… more convenient | No real user. The “so that” says nothing about what changes | Name the customer and situation; the “so that” is about knowing they have a place |
| Slots with a free room (AC1) | Wrong rule. It needs a free room and a free therapist | Show only times with at least one room and one therapist free for the whole service |
| SMS confirmation (AC2) | This channel is not in the context. The owner has not decided | Confirmation screen for the customer, email for the spa. Messaging goes to open questions |
| Favourite therapist (AC3) | Out of scope this time | Removed. Already listed as not in scope |
| Free cancellation 24 hours ahead (AC4) | The AI made up the number. Cancelling is also out of scope | Removed. Becomes its own story once the owner sets a cancellation policy |
| Quick and easy to use (AC5) | Cannot be tested | Removed. If a time limit is needed, agree it with dev and write the number |
| Reminder 1 hour before (AC6) | New feature, new number | Removed. Added to the backlog to ask the owner later |
| (not in the draft) | Missing the 2-hour booking rule, the 20:00 end time, and two customers choosing the same slot | Three criteria added, see the final version below |
Look at the middle column. None of the fixes needed writing skill. Every one needed something the AI did not have: the spa's real rules and a decision about scope.
The AI's open question about logging in was useful too. It showed the PO something they had not written down. After asking, the owner chose not to require login, so the final version only asks for a name and phone number.
What does the final story with acceptance criteria look like?
This is the version after the PO's fixes and a read-through with dev and QA. You can copy it as a frame for your own story.
Short name: Customers book online As a customer who wants to book at Huong Buoi spa when the spa has not had time to reply to messages, I want to pick a service and an open time on the website myself, so that I know I have a place without waiting for the spa to message me back. In scope this time: choose a service, choose a date and time, enter name and phone number, confirmation screen, email to the spa. Not in scope this time: online payment, choosing a therapist, changing or cancelling a booking, reminder messages. Acceptance criteria: 1. Given a customer has chosen a 90-minute service, When they open the list of times for a day, Then only times with at least one free room and one free therapist for the full 90 minutes are shown. 2. Given a customer has chosen a 90-minute service, When they open the list of times, Then the latest start is 18:30, so the service ends at 20:00. 3. Given it is now 14:10, When a customer opens today's list of times, Then the earliest start is 16:30. 4. Given a customer has chosen a time, When they enter a name and phone number and tap Book, Then the screen shows the booked date, time and service, and the spa receives an email with the same details. 5. Given the phone number is empty, When the customer taps Book, Then no booking is created and the phone field shows an error. 6. Given 17:00 has one place left, When two customers tap Book for it at the same time, Then only one booking is created; the other customer sees that the time has just filled and can pick another. Open questions: - Do we send the customer a confirmation message? (the owner decides) - What counts as a valid phone number? (dev proposes, the owner approves) - Exact wording of the error messages. (PO agrees with the owner)
Six criteria, each with a clear pass or fail. Every number traces back to context the owner confirmed. For example, 16:30 in criterion 3 comes from two rules: book at least 2 hours ahead, and start times in 30-minute steps.
What was cut is not lost. Cancelling and reminders become separate backlog items, waiting for the owner to set the rules.
Should you ask AI to review the fixed version?
Yes, but give it a different role. You no longer need it to write more. You need it to point out what is still vague.
Here is an agreed user story with acceptance criteria. Act as a QA engineer reading them for the first time. For each criterion, say which action you would test it with, and where you would look to see it pass. List any criterion that does not answer both, with the question you would ask the PO. Do not add new criteria. [paste the story and acceptance criteria]
The output of this step is a list of questions, not decisions. Take the sensible ones back to the owner or dev, then update the ticket.
Common mistakes when using AI to write user stories
- Giving one line of request and no context. The AI fills the gaps with whatever sounds most plausible.
- Keeping “As a user”. Who the user is decides which times, which screens and which cases matter.
- Keeping a criterion because it sounds good. An out-of-scope feature in the AC becomes real work for the team.
- Ignoring the open questions. They are often the most useful part of the draft, because they show what you have not decided.
- Pasting real customer data into the prompt. A context like the one above needs nobody's name or phone number.
I am collecting prompts with sample outputs like this one into an AI resource library for POs. If you want to hear when it opens, leave your email below.
Frequently asked questions
Does this prompt work with ChatGPT?
Yes. The prompt does not depend on a tool. Results vary between tools and between runs, so the reading and fixing step is the same either way.
Can AI write the acceptance criteria too?
Yes, it can draft them in Given / When / Then. But the numbers, limits and scope in them must come from agreed rules, not from the AI.
How much context should go into the prompt?
Enough that a new colleague could write the story without asking you anything: who is struggling, how they cope today, the agreed rules, what is in scope and what is not.
Should I paste meeting notes or customer messages into the prompt?
Only if your company allows that tool with that data. Usually you only need to summarise the context in your own words, with no one's name or phone number.
Sources to check
Related articles
- What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
- What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
- 5 AI prompts I reuse every sprint as a PO: Five copy-ready prompts for research, user stories, acceptance criteria, edge cases and AI agent briefs, each with the check a PO should never skip.
- AI agent brief template for product owners: A seven-line AI agent brief template for product owners: goal, scope, checks and stopping points, with an illustrative example and a table of common mistakes.