Free User Story Generator (With Acceptance Criteria)

TL;DR: This free user story generator is a copy-paste AI prompt. Paste a feature idea and it returns user stories in the "As a, I want, so that" format, acceptance criteria as a checklist or Gherkin Given/When/Then scenarios, an INVEST check, and a list of open questions instead of invented requirements. Works in ChatGPT, Claude and Gemini.

A user story generator AI prompt is only as good as what it refuses to do. Every model can produce a tidy "As a user, I want..." sentence. The hard part is getting stories that a team can estimate and test, with acceptance criteria specific enough to settle an argument in sprint review, and without the model quietly inventing business rules nobody agreed.

This page gives you the generator, a Gherkin variant for teams that automate acceptance tests, an epic splitter, and a review prompt. They are free, and they work in any AI chat.

No signup is needed to use them. Copy a prompt, replace the bracketed fields with your own feature, and paste it into whichever assistant your team already uses. The prompts are written as plain text on purpose, so they survive being pasted into a ticket, a wiki page or a shared prompt library without losing their structure. If you only take one thing from this page, take the generator's rule about open questions. It is the difference between a draft that saves your team time and one that quietly adds work later.

What Makes a User Story Worth Generating?

A story is a prompt for a conversation, not a specification. Mike Cohn's user stories guide gives the common template as:

"As a [type of user], I [need/want/am required] to [do something], so that [reason or benefit]."

The same guide notes that "Ron Jeffries described user stories with three words: card, conversation, and confirmation." The card is the sentence. The conversation is where the team works out the details. The confirmation is how you know the story is done, and that is where acceptance criteria live.

That framing tells you what an AI generator is good for. It can write the card and draft the confirmation. It cannot have the conversation for you, but it can prepare it, by listing what it did not know.

The second standard worth building in is INVEST, which Bill Wake published on his site in 2003: Independent, Negotiable, Valuable, Estimable, Small, Testable. His note on the last letter is the one generated stories most often fail. Writing a story card, he says, carries an implicit promise: "I understand what I want well enough that I could write a test for it." A model will happily write stories that break that promise unless you make testable acceptance criteria part of the output.

The Free User Story Generator Prompt

Copy this, fill in the brackets, and paste it into your AI chat. The more specific your users and constraints, the less the model has to guess.

Role: senior product manager writing sprint-ready user stories.

Feature idea: [DESCRIBE THE FEATURE IN 2-5 SENTENCES]
Users involved: [LIST USER TYPES, e.g. account admin, first-time buyer]
Goal / outcome: [WHAT CHANGES FOR THE USER OR THE BUSINESS]
Known business rules: [LIST ANY RULES, LIMITS, PERMISSIONS]
Out of scope: [WHAT THIS WORK WILL NOT DO]
Product context: [PRODUCT TYPE, PLATFORM, RELEVANT EXISTING FEATURES]
Acceptance criteria format: [CHECKLIST or GHERKIN]

Task:
1. Write 3-8 user stories in the form
   "As a [user], I want [capability], so that [benefit]."
   Each story must deliver something a user can see or use.
2. For each story, write acceptance criteria in the chosen format.
   Every criterion must be testable: a tester could say pass or fail
   without asking anyone.
3. Include at least one criterion per story for an error, empty or
   edge case.
4. Check each story against INVEST (Independent, Negotiable,
   Valuable, Estimable, Small, Testable). Mark any letter it fails
   and say why in one line.
5. List open questions: anything you needed to know but was not in
   my input.

Hard rules:
- Use only the business rules I gave you. If a story needs a rule I
  did not give, do not invent one: write [OPEN QUESTION] in the
  criterion and add it to the open questions list.
- No technical implementation details (databases, frameworks, APIs)
  unless I listed them in product context.
- No estimates or story points.

Output format:
## Story 1: [short title]
**Story:** As a ...
**Acceptance criteria:**
...
**INVEST check:** pass / fails on [letter]: [reason]

(repeat for each story)

## Open questions
- ...

Three instructions in that prompt do most of the work.

"Use only the business rules I gave you." Without it, a model asked for a password reset story will decide your reset links expire in 24 hours. That may be right. It may also contradict your security policy, and nobody notices until QA. The [OPEN QUESTION] marker turns every guess into a visible gap.

"At least one criterion per story for an error, empty or edge case." Generated criteria skew toward the happy path. Forcing one unhappy path per story catches the cases teams forget until production.

"No estimates or story points." Estimation belongs to the team that will build the story. A model's number anchors the discussion and has no basis in your codebase.

How Do You Get Acceptance Criteria in Gherkin?

Set the format field to GHERKIN and add the block below to the prompt. Gherkin is the language Cucumber uses for executable specifications, and its reference documentation defines the three core step types:

• "Given steps are used to describe the initial context of the system - the scene of the scenario."
• "When steps are used to describe an event, or an action".
• "Then steps are used to describe an expected outcome, or result."

The same reference lists And and But as additional step keywords, and Scenario Outline with Examples for running one scenario against several rows of data.

Gherkin rules for the acceptance criteria:
- For each story, write a Feature block with 2-5 Scenarios.
- Each Scenario uses Given (starting context), When (one action or
  event), Then (observable outcome). Use And/But only to extend a step.
- One When per scenario. If you need two actions, write two scenarios.
- Then steps must describe something a user or tester can observe,
  not internal system state.
- Where the same scenario applies to several inputs, use a
  Scenario Outline with an Examples table.
- Use a Background only for Given steps shared by every scenario
  in the Feature.
- Use the exact keyword spelling and colons of standard Gherkin:
  "Feature:", "Background:", "Scenario:", "Scenario Outline:",
  "Examples:". Step keywords (Given/When/Then/And/But) take no colon.

That last rule is not pedantry. The Cucumber reference warns: "If you add a colon after a keyword that should not be followed by one, your test(s) will be ignored." Models add colons after Given more often than you would expect, and a silently ignored test is worse than no test.

Here is what the output looks like for a simple story:

Feature: Save a draft invoice
  As a freelancer, I want to save an unfinished invoice as a draft,
  so that I can finish it later without losing my work.

  Background:
    Given I am signed in
    And I have started a new invoice

  Scenario: Saving a draft with a client selected
    Given I have selected a client
    When I choose "Save as draft"
    Then the invoice appears in my Drafts list
    And the invoice status shows "Draft"

  Scenario: Leaving the page with unsaved changes
    Given I have entered at least one line item
    When I try to leave the invoice page
    Then I am asked whether to save the invoice as a draft

  Scenario Outline: Drafts are not sent
    Given I have a draft invoice for <client>
    When I open the client's invoice history
    Then the draft is not listed as sent

    Examples:
      | client        |
      | Acme Studio   |
      | North Bakery  |

Which format should you pick? It depends on who reads the criteria.

How Do You Split an Epic Into User Stories With AI?

Give the model the epic and ask it to split along named lines, then check every piece is still valuable on its own. Wake's INVEST piece compares a whole story to a multi-layer cake and says that when you split one, you want each slice to give the customer the essence of the whole. That rules out the most common bad split, one story per technical layer.

Role: product manager preparing a backlog.
Task: split the epic below into user stories that can each ship on
their own and still be useful to a user.
Epic: [PASTE EPIC]
Users: [LIST]
Constraints: [DEADLINES, DEPENDENCIES, TEAM SIZE IF RELEVANT]

Split using whichever of these fit, and say which you used:
- steps in the user's workflow
- business rules or variations
- user types or permission levels
- data variations or input types
- simple case first, then complex cases

Rules:
- Never split by technical layer (e.g. "build the API", "build the UI").
- Each story must pass the Valuable test: a user gets something.
- Flag any story that still looks larger than one sprint.
- Suggest an order, and note dependencies between stories.
Output: a numbered list of stories, then the flags and the order.
Then I will run the generator prompt on each story.

Run the generator on each story afterwards to get the acceptance criteria. Doing both in one pass tends to produce shallow criteria, because the model spends its effort on the split.

How Do You Stop the Generator Inventing Requirements?

Three habits, in order of how much trouble they save.

Give it the rules, or give it permission to ask. The generator already turns missing rules into [OPEN QUESTION] markers. Take those questions to refinement. They are often the most valuable output of the whole exercise, because they are exactly the questions a developer would otherwise ask halfway through the sprint.

Keep a product context it can reuse. Personas, a glossary, permission levels and platform constraints should not be retyped every time. Our guide to keeping product context in every AI chat covers how to build one. With a context in place, the "Product context" field in the generator shrinks to a single line.

Review before refinement, not after. Run this review prompt on the output before a human reads it. It catches the obvious problems so the team's time goes to the real ones.

Role: agile coach reviewing a backlog before refinement.
Task: review the user stories below.
Stories: [PASTE GENERATOR OUTPUT]
For each story:
1. Score INVEST: which letters fail, and why (one line each).
2. Quote any acceptance criterion that is not testable, and rewrite it.
3. Flag any criterion that states a business rule not present in
   this original input: [PASTE ORIGINAL FEATURE IDEA AND RULES]
4. Flag duplicate or overlapping stories.
Finish with the three most important questions for the product owner.

Point 3 is the important one. It compares the output against your original input and catches rules the model introduced despite being told not to.

What Does the Whole Flow Look Like on a Real Feature?

Take a common request: "Let admins invite teammates by email." A product manager fills in the generator with two user types (workspace admin, invited teammate), the rule that invitations need an email address, the out-of-scope note that single sign-on is not part of this work, and the checklist format.

The output comes back with five stories: send an invite, accept an invite, resend an invite, revoke a pending invite, and see who is pending. Each has four to six criteria. The open questions list is the interesting part. It asks how long an invite stays valid, whether an admin can invite someone who already belongs to another workspace, what happens when a workspace reaches its seat limit, and whether invited users get the admin's permissions or a default role.

None of those were in the original request. All four would have blocked a developer. The review prompt then flags the "see who is pending" story as failing Independent, because it depends on the invite story shipping first, which is fine and simply goes into the order.

Twenty minutes of work produced a draft backlog and a refinement agenda. The team still decides the answers.

For the step before this one, turning meeting notes into a spec, see the product manager's meeting-notes-to-spec workflow. For a broader set of PM prompts, including PRDs and roadmaps, see 30 AI prompts for PRDs, user stories and roadmaps. And if your team also writes quarterly goals, our sibling guide to AI prompts for writing OKRs uses the same testable-outcome discipline.

Which Mistakes Do AI-Generated User Stories Make Most Often?

Five show up again and again when teams start generating stories. Each has a fix you can add to the prompt.

The generic user. "As a user" tells the team nothing about who needs the capability or what they already know. The guide linked above makes the same point with a deliberately weak example, "As a user, I want reports so that I can see information." Fix it by naming real user types in the input, and add a rule that "user" alone is not allowed.

The benefit that repeats the want. "I want to export invoices so that I can export invoices" is common in generated output. Add a rule that the "so that" clause must name an outcome for the user or the business, not restate the capability.

Criteria that describe the solution. "A blue button appears in the top right" is a design decision, not an acceptance criterion, unless the design has already been agreed. Ask for criteria that describe what the user can do and observe, and leave the layout to design.

The vague pass condition. "The page loads quickly" or "errors are handled gracefully" cannot be passed or failed. The generator's testability rule catches most of these; the review prompt catches the rest. If the team cares about speed, the criterion needs a number the team has agreed, and that number is an open question until someone agrees it.

Too many stories. Ask for "all the stories" and a model will produce twenty, half of them overlapping. The 3 to 8 range in the generator keeps the output reviewable. For bigger work, split the epic first and generate per story.

Can the Generator Handle Technical or Non-Functional Work?

Partly, and it should not force everything into the user story template. The Mountain Goat guide says so directly: "Some technical work is clearer as a technical backlog item." A database migration written as "As a developer, I want the schema migrated so that..." helps nobody.

For non-functional needs such as performance, accessibility or security, Wake's INVEST piece suggests treating them as things that need to be tested, and that is the useful move with AI too. Ask the generator to add non-functional acceptance criteria to the stories they affect, each with an [OPEN QUESTION] where a threshold has not been agreed. For pure technical tasks, skip the template and ask for a plain task description with a clear definition of done.

What Should You Not Paste Into the Generator?

Anything your company's AI policy excludes, and anything the terms of your AI account do not cover. Consumer and business accounts from the major providers are governed by different data terms, so check which one your team is actually using. For confidential roadmap work, describe the feature generically, drop customer names and unreleased product names, and replace internal system names with plain descriptions. The generator does not need them to write good stories.

How Does a Product Team Share One Generator?

Store it once, version it, and let everyone use the same copy. When each PM keeps a private version, the team's stories drift apart in format and quality, and improvements never spread. Our guides to reusable prompt variables for teams and version control for team prompts cover the mechanics.

This is where Prompt Architects fits a product team. The generator lives in a shared library, the product context lives in a shared context, and repeated details such as product name or platform can be stored as global variables, all inside the AI chat your team already uses. The Free plan includes 5 prompt enhancements per day, according to the FAQ page, which is enough for one PM to try this. For a team, the Team plan is $10 a month plus $3.50 per member, for 2 to 20 members, at the time of writing, per the pricing page. Check that page for current figures. For a wider look at the category, see the best AI tools for product managers.

The Short Version

A useful user story generator does four things: writes stories in a consistent format, writes acceptance criteria a tester can pass or fail, refuses to invent rules, and hands you the questions it could not answer. The prompt above does all four, in checklist or Gherkin form. Split epics with the splitter, run the review prompt before refinement, and treat the open questions as your agenda. The model drafts; the team decides.