User stories fail for two reasons: they’re too big to ship in one sprint, or too vague for QA to write a test against. The prompts below force atomic shape, testable Given/When/Then acceptance criteria (AC), and explicit coverage of edge and negative paths — the parts most AI drafts skip. Paste a feature, a bug, or an interview transcript and get backlog-ready tickets.
TL;DR
- 12 prompts that map to real grooming moments: decompose a feature, mine edge cases, split a too-large story, rank a backlog, generate the API contract.
- Every prompt demands a named persona (never “user”), AC as numbers not adjectives, and a regression test where it matters.
- For long backlogs and transcripts, paste into a 1M-token model — Claude Opus 4.7, Gemini 3.1 Pro, or GPT-5.5 (all 1M context as of June 2026). For quick one-off splits, any free tier works.
- Want the full walkthrough from idea to backlog? See Write User Stories With AI. For the AC layer specifically, see Acceptance Criteria Prompts.
Best for
- Agile teams (Scrum / Kanban) doing sprint planning and grooming
- Vendor / contractor handoff where ambiguity costs money
- Writing Jira or Linear tickets at speed
- Converting a PRD into a backlog
- Turning bug reports and interview notes into capabilities
Which model to use (June 2026)
All three frontier models handle story drafting well; the differences show up at scale.
| Model | Context | Where it shines for stories | Notes |
|---|---|---|---|
| Claude Opus 4.7 | 1M tokens | Long transcripts, dependency reasoning, AC rigor | Pro $20/mo, Max $100/$200 |
| Gemini 3.1 Pro | 1M tokens | Pasting an entire Confluence PRD at once | Google AI Pro $19.99/mo |
| GPT-5.5 | ~320 pages in-app (Plus); 1M on $200 Pro | Fast single-story splits, the picker’s Thinking mode for prioritization | Plus $20/mo |
If you live in your tracker, the AI is now built in: Atlassian’s Rovo drafts Jira issues inline, and Linear converts a one-liner into a spec in seconds (Linear AI is bundled into its paid tiers without metered token charges as of April 2026). Jira’s Standard plan runs roughly $8/user/mo (monthly billing, cheaper annually); Linear’s free tier caps you at 250 issues before you need a paid plan. Use the prompts below to set the bar regardless of where you draft.
1. Story from a feature
Feature: [description]. Decompose into atomic user stories. Each must:
- Use "As a [role], I want [action], so that [benefit]" format
- Be shippable in <=3 days by one engineer
- Have 3-5 acceptance criteria in Given/When/Then format
- Name the persona explicitly (not "user")
Output as a markdown table: Story | Role | AC Count | Estimated Days.2. Story for an edge case
Main happy-path flow: [description]. Write 5 edge-case user stories the main flow must handle:
1. Error state (e.g. API down)
2. Empty state (no data yet)
3. Maximum state (boundary / overflow)
4. Concurrent state (two users acting at once)
5. Slow-network state (degraded performance)
Each with full AC. Mark which are MVP vs P2.3. Negative-path user stories
For feature [feature], write 4 negative-path stories. For each:
- What the user should NOT be able to do
- What the system must prevent (permission, validation, rate limit)
- How the block is communicated (error message, disabled UI, silent fail)
- The test that would catch a regression
Format as proper user stories with AC.4. Story prioritization
Below are 12 user stories. Rank by impact x effort using a 2x2. For each:
- Impact score 1-5 with one-line justification tied to a metric
- Effort score in person-days
- Quadrant placement (quick win / big bet / fill-in / time-sink)
Mark must-haves for MVP and what to defer to v1.1.
[paste]5. Story to tasks breakdown
For the user story below, decompose into 5-8 implementation tasks. Each:
- <=1 day of work
- Owned by one role (design, backend, frontend, QA, devops)
- With a clear "done" definition
- Sequenced (mark dependencies)
Include explicit test tasks separate from build tasks.
[paste story]6. Story dependency map
Below are stories. Identify dependencies between them (story A blocks story B). Output:
- A text-format DAG showing edges
- The critical path (longest chain)
- Suggested ship order grouped by sprint
- Any stories with no dependencies (can ship anytime)
[paste]7. Story rewrite for clarity
Below are 5 vague user stories. Rewrite each so:
- Actor is a specific persona, not "user"
- Action is a verb the system must support, not an outcome
- Benefit is testable / measurable, not "better UX"
- AC are unambiguous (no "should be fast" — use a number)
Show before/after side by side.
[paste]8. Acceptance criteria check
Below is a user story plus AC. Audit and flag:
- AC that aren't testable (subjective words like "smooth", "intuitive")
- Missing negative-path AC (only happy path covered)
- AC that hides multiple stories (one Given/When/Then = one story)
- AC that duplicates UI spec instead of behavior
For each flag, propose a rewrite.
[paste]9. Story from a bug report
Bug report: [paste]. The underlying issue is a missing capability. Reframe as 1-2 user stories that, if shipped, would prevent this class of bug. AC must include the regression test for this specific bug.10. Story from a user interview transcript
Below is a 30-minute user interview. Extract 4-6 user stories the interviewee implied (not asked for verbatim). For each:
- The exact quote that supports it
- Persona inferred from context
- AC grounded in the workflow they described
Flag any "story" that's actually just venting and shouldn't be built.
[paste transcript]11. Story splitting (too-large story)
Below is a user story too large to ship in a sprint. Split using SPIDR (Spike, Path, Interface, Data, Rule). Output the split with:
- Which technique was applied
- Each resulting story sized at <=3 days
- Which sub-story is the thinnest valuable slice (ship first)
- What's deferred and why it's safe to defer
[paste]12. Story to API contract
For the story below, draft the API contract needed to satisfy AC:
- Endpoint(s), method, path
- Request schema with example
- Response schema with example for success plus each error case
- Status codes mapped to AC outcomes
- Idempotency / auth requirements
Format as OpenAPI-flavored YAML.
[paste]How to grade what the AI gives back
Run every generated story through INVEST (Bill Wake’s checklist): Independent, Negotiable, Valuable, Estimable, Small, Testable. A story that fails “Small” gets fed to prompt 11; one that fails “Testable” goes to prompt 8. SPIDR (Mike Cohn) is the splitting counterpart — a healthy sprint holds roughly 6-10 INVEST-sized stories, so anything an AI sizes above three days is a candidate to split. Treat the model as a fast first-drafter, not the product owner: it will happily invent personas and pad AC, so prune anything not grounded in your actual users.
Common mistakes
- Stories too large to finish in a single sprint (split with SPIDR, prompt 11)
- AC that aren’t testable — “the page should feel responsive” is not AC; “first contentful paint under 1.5s on 4G” is
- Mixing multiple stories into one (each Given/When/Then is its own story)
- Skipping negative path and edge cases until QA finds them in staging
- Using “user” as the role — no persona means no real, testable benefit
- Shipping AI output unedited; the model doesn’t know your data model, so it guesses
FAQ
Which AI model writes the best user stories? For day-to-day drafting, any current model is fine. At scale — a 30-minute transcript or a full PRD — reach for a 1M-token model: Claude Opus 4.7, Gemini 3.1 Pro, or GPT-5.5 (all 1M context as of June 2026). Opus 4.7 tends to be strongest at AC rigor and dependency reasoning; Gemini 3.1 Pro is convenient if your docs already live in Google Workspace.
Should I use these prompts or just Jira’s built-in AI? Use both. Atlassian Rovo and Linear’s AI are great for drafting a ticket where you already work, but they apply the org’s default phrasing, not the INVEST/SPIDR discipline. Paste these prompts in to set a higher bar, then move the cleaned-up stories into your tracker.
What’s the difference between a user story and acceptance criteria? The story states who, what, and why (“As a [persona], I want [action], so that [benefit]”). AC are the testable conditions that prove it’s done, usually in Given/When/Then form. One story typically has 3-5 AC. For AC-specific prompts, see Acceptance Criteria Prompts.
How big should one story be? Small enough that one engineer ships it in three days or less, and small enough that 6-10 fit in a sprint. If it’s bigger, split it with SPIDR before estimating.
Can the AI estimate story points? It can suggest relative sizing and flag outliers, but it can’t see your codebase or team velocity, so treat its person-day numbers as a starting anchor for the team’s own estimation, not the final figure.