AI User Stories: Write Acceptance Criteria That Hold Up

AI user stories are a fast way to turn a rough feature idea into a backlog of small, testable pieces of work: who needs something, what they need and why, plus the acceptance criteria that tell a team when the story is done. An assistant can produce a dozen of them in a minute. The risk is that a dozen plausible-sounding stories can hide the fact that no one has decided what the product is for. This guide shows how to use an assistant to write user stories that survive contact with developers, testers and customers.

It is written for product managers, founders, business analysts, project managers and developers who write their own tickets. The method works with any assistant. Examples use Ask Mio, which includes a Product manager expert for specs, user stories, roadmaps and prioritisation.

What a good user story contains

A user story is a short description of a need from the user’s point of view, usually written in a fixed pattern: “As a [type of user], I want [capability], so that [benefit]”. The pattern is a prompt for conversation, not a specification in itself. The background is summarised in the article on user stories, and the Atlassian guide shows how teams use them in planning.

A useful story has four parts:

1. A real user type. “Customer” is vague. “First-time buyer who has not created an account” is something a designer can act on.
2. A capability, not a solution. “I want to save my basket for later” leaves room for design. “I want a heart icon in the top right corner” decides it too early.
3. A benefit. The “so that” clause is where weak stories show themselves. If you cannot write it, you may not need the story.
4. Acceptance criteria. Specific, checkable statements that define done.

A common test of quality is the INVEST checklist: independent, negotiable, valuable, estimable, small and testable. Ask the assistant to check each story against it, and treat a failure on “small” or “testable” as the most important signal.

AI user stories: what to give the assistant

The assistant knows the pattern, but it does not know your product, your users or your constraints. Supply them. The more of the following you include, the less generic the stories will be.

• The product and its purpose in two or three sentences.
• The user types and what distinguishes them, such as admin, member, guest or support agent.
• The feature or goal, written as a problem to solve rather than a solution.
• Constraints: platforms, regulations, existing systems, deadlines.
• What is out of scope. This prevents invented extras.
• Examples of your team’s existing stories, so the format and level of detail match.

A good prompt reads: “Product: a booking tool for small dental clinics. Users: receptionist, dentist, patient. Goal: reduce missed appointments. Out of scope: payments and insurance. Write ten user stories in our format, each with three to five acceptance criteria in Given-When-Then form. Flag any story that depends on a decision we have not made.”

Writing acceptance criteria that testers can use

Acceptance criteria are where stories become real. Weak criteria say “the page should be fast” or “the user can easily cancel”. Strong criteria describe observable behaviour and can be turned directly into tests. Two formats are common.

Format	Shape	Best for	Watch out for
Given-When-Then	Given a context, when an action happens, then an outcome is visible	Behaviour with clear steps, test automation	Becoming long scripts instead of short rules
Rule list	A short bullet list of conditions that must be true	Validation, permissions, calculations	Vague bullets that cannot be checked
Example table	Inputs and expected outputs in rows	Pricing, discounts, date logic	Missing edge cases

A worked example. Story: “As a receptionist, I want to send a reminder message to a patient, so that fewer appointments are missed”. Criteria in Given-When-Then form might be:

• Given an appointment more than 24 hours away, when the receptionist selects Send reminder, then the patient receives a message with the date, time and clinic address.
• Given a patient with no mobile number on file, when the receptionist selects Send reminder, then the button is disabled and a message explains why.
• Given a reminder was already sent today, when the receptionist selects Send reminder again, then the system asks for confirmation before sending.

Ask the assistant to propose the edge cases after the happy path: empty fields, duplicates, permissions, time zones, failures of an outside service and what the user sees when something goes wrong. These are the cases that tickets most often leave out. Our guide to AI-generated tests shows how to turn the criteria into automated checks.

A workflow that avoids generic backlogs

Step 1: Start from the problem

Before asking for stories, ask the assistant to restate the problem and list assumptions it is making. Correct them. This single exchange prevents most off-target output.

Step 2: Generate an epic outline

Ask for five to eight themes or epics, each with one sentence of purpose. Cut and merge them yourself. Product judgment lives here.

Step 3: Break one epic into stories

Work one epic at a time. Ask for stories that deliver value on their own, ordered by dependency. Reject stories that are really tasks (“create a database table”) unless they are genuinely user-visible.

Step 4: Add acceptance criteria and questions

Ask for criteria and a list of open questions for each story. Questions are often more valuable than answers: “Who can cancel a reminder?” is a decision your team needs to make.

Step 5: Size and split

If a story would take more than a few days, ask the assistant to split it along user-visible lines: by user type, by rule, by data variation or by happy path versus exceptions. Avoid splitting by technical layer.

Step 6: Review with the team

Stories are a conversation tool. Bring the draft to refinement and let developers and testers question it. The assistant’s output is a starting point for that discussion, never its replacement.

Common mistakes with generated stories

Solution-first stories

Assistants often slip into design: “As a user, I want a dropdown menu to select a category”. Rewrite as the need (“choose a category”) and let design decide the control.

Missing “so that”

Generated benefits are frequently circular: “so that I can use the feature”. Ask for a real outcome tied to a goal or metric. If none exists, question the story.

Stories that are really tasks

“Set up the analytics dashboard” is a task. “As a manager, I want to see weekly sign-ups by channel, so that I can decide where to spend” is a story.

Hidden dependencies

A story that needs another story to be done first should say so. Ask the assistant to list dependencies, then check them against your actual system.

Invented details

Assistants fill gaps with plausible specifics: a number of days, a limit, a legal rule. Mark every number and rule you did not supply as “to confirm” until a person with authority has decided.

Ignoring non-functional needs

Accessibility, performance, privacy, audit trails and error handling are easy to omit. Ask for a separate list of non-functional criteria and see if they apply to each epic. For tickets that touch personal data, our AI privacy checklist for business is a good prompt for what to add.

Beyond stories: related documents

User stories rarely stand alone. An assistant can help with the neighbouring documents, as long as you keep them consistent.

• Product requirements: a short document explaining the problem, goals, non-goals and success measures that frames the stories.
• Roadmaps: themes by quarter, derived from epics, with the caveat that dates are decisions, not predictions.
• Release notes: a plain-language summary derived from completed stories.
• Test plans: scenarios derived from the acceptance criteria.

Keep the stories as the single source of truth and regenerate the others from them, rather than letting each document drift. Our guides for AI for product managers and AI for project managers cover related tasks.

Working across a team

If several people write stories, agree on a template and put it in a shared project. On Ask Mio’s Business plan, team and shared projects let colleagues use the same instructions and files, such as the product description, the glossary and the story template. Everyone then gets stories in the same format. Business includes 5 seats according to the live pricing page. For solo work, a personal project with the same instructions does the job, and memory on paid plans lets Mio keep preferences you ask it to remember.

A small team habit helps: store a handful of your best past stories as examples in the project, and refresh them every few months. The assistant matches the style of what it is shown.

Measuring whether the stories worked

Stories are only useful if the team builds the right thing. After a release, compare what shipped with the benefit written in each “so that” clause. If a story promised fewer missed appointments, check whether missed appointments fell. Bring any story whose benefit you cannot measure back to refinement and ask what evidence would show it worked. The assistant can suggest metrics and ways to collect them, but the decision about what counts as success belongs to the product owner.

Privacy and confidentiality

Backlogs often describe unreleased features, customers and commercial plans. Paste only what you are allowed to share with an external service, and remove customer names and personal data from examples. Check your company’s AI policy before using any assistant on internal documents. Ask Mio’s public pages state that user data is not used to train models and that chats can be exported or deleted, but you should always confirm that a tool meets your own requirements.

Cost and plan notes

Writing and reviewing stories is a Chat or Write task. The free plan includes 600 points a month, and a normal chat reply costs 1 point while a long one costs 3, per the pricing page. A full epic with stories and criteria is a few exchanges. Uploading a requirements document as a PDF or Word file needs a paid plan from €5 a month.

Frequently Asked Questions

Can AI write all my user stories?

It can draft them quickly, but it cannot decide what your product should do. Use it to propose stories, edge cases and acceptance criteria from a clear problem statement, then edit with your team. Stories written without product judgment tend to be generic, circular and full of details nobody has agreed on.

What is the best format for acceptance criteria?

Given-When-Then works well for behaviour with clear steps and maps directly to tests. A short rule list suits validation and permissions, and an example table suits calculations. Pick the format your testers can use, keep each criterion checkable, and avoid vague words such as easy, fast or intuitive.

How many user stories should an epic have?

There is no fixed number, but most epics break into roughly five to fifteen stories that each fit within a few days of work. If an epic has far more, it is probably several epics. If a story is too large to finish in a sprint, ask the assistant to split it along user-visible lines.

Should I give the assistant my real customer data?

No. Use anonymised or invented examples, and describe user types instead of naming people. Backlogs often contain unreleased plans, so check your company’s policy before pasting them into any external service, and keep sensitive details in your own tools. A short example with invented names usually gives the assistant everything it needs to match your format.

How do I stop generated stories sounding generic?

Provide the product purpose, real user types, constraints, out-of-scope items and examples of your best past stories. Ask the assistant to list its assumptions before it writes anything. Specific input leads to specific output, and correcting assumptions early is faster than rewriting a whole backlog.

Is it free to try?

Yes. The free plan covers Chat and Write with 600 points a month and needs no card, which is enough to draft stories for one feature. Paid plans add file uploads, memory and more points. The current details are always on the pricing page.

The Bottom Line

AI user stories are most valuable when you supply the product context and use the assistant to explore edge cases, write acceptance criteria and surface open questions, rather than to invent the backlog. Start from the problem, work one epic at a time, split by user-visible value and take every draft to your team. To try the method on one feature, begin on the free plan and see what team projects add on the Ask Mio pricing page.