User stories fail when they’re too big to ship in a sprint, or too vague for QA to write a test against. These prompts enforce atomic shape, testable acceptance criteria, and explicit handling for edge and negative paths. For an end-to-end walkthrough from feature idea to backlog, see Write User Stories With AI.
Best for
- Agile teams (Scrum / Kanban)
- Sprint planning + grooming
- Vendor / contractor handoff
- JIRA / Linear ticket writing
- PRD → backlog conversion
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 × 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 → tasks breakdown
For 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 + 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 → API contract
For story below, draft the API contract needed to satisfy AC:
- Endpoint(s), method, path
- Request schema with example
- Response schema with example for success + each error case
- Status codes mapped to AC outcomes
- Idempotency / auth requirements
Format as OpenAPI-flavored YAML.
{paste}Common mistakes
- Stories too large to finish in a single sprint (split with SPIDR)
- AC that aren’t testable — “the page should feel responsive” is not AC
- 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 benefit