How do I split a large user story?

Slice by outcome, not UI. Ship the smallest end‑to‑end value: one persona, one happy path, one data shape. Keep a parent epic to retain broader context and non-negotiables.

Should technical implementation details be included in user stories?

Only when constraints materially impact the solution (e.g., offline capability, performance budgets, compliance). Otherwise capture the behavior and outcomes; engineering decides how.

How many stories should we plan given our velocity?

Plan using median/P85 velocity instead of the average of a few sprints. If P85 is 20 points, plan ~20 and leave slack for bugs and reviews to avoid chronic carryover.

What are common user story anti-patterns?

No explicit user value, vague outcomes ("optimize"), solutioning in the story (e.g., specifying a technology stack), and hidden epics with multiple outcomes in one ticket.

Do non-functional requirements belong in user stories?

If they change the work, include them as acceptance criteria (performance, a11y, security). If they are global standards, link to the policy and reference it in the story.

How do I write user stories for back-end or platform work?

Use internal consumers as the user (service, team). Define contracts (API, schema, SLAs) and write BDD acceptance that a service test can validate. Value is reliability, latency, or cost.

When should a user story become an epic?

If it spans multiple personas/paths or requires cross-team coordination, or repeatedly spills across sprints, promote it to an epic and deliver value slices as separate stories.

User Story Creator

Q: How detailed should acceptance criteria be before sprint planning?

Detailed enough that engineering can automate tests without clarifying what "done" means. Typically 3–6 GIVEN/WHEN/THEN lines. If you need 12+, you're holding an epic, not a story.

Q: What's the difference between a user story and a requirement document?

User stories capture user value and behavior; requirement docs capture comprehensive scope, constraints, and edge conditions. Promote to an epic + spec if extensive context is required.

Q: Example of a good user story with BDD acceptance?

As a project manager, I want overdue task reminders so teams close tasks on time. GIVEN a task overdue by 24h, WHEN reminders run, THEN send one email to the assignee and log an event, AND skip weekends.

Transforms features into INVEST-compliant user stories

documentationPopularbeginnerINVESTBDDJTBD800-1200 words

Customize Your Prompt

Fill in the variables to generate your personalized prompt

Feature Description

User Type

Additional Context (Optional)

Preview

See how your prompt will look with the current variables

You are a Senior Product Manager creating user stories for [Feature Description] for [User Type].

Create 3-5 user stories following the INVEST framework (Independent, Negotiable, Valuable, Estimable, Small, Testable):

## USER STORY FORMAT:
**As a** [user persona with specific context]
**I want** [specific capability/action]
**So that** [business value/outcome using JTBD framework]

## For each story, provide:

### ACCEPTANCE CRITERIA (BDD Format):
GIVEN [initial context/precondition]
WHEN [action/trigger occurs]
THEN [expected outcome/behavior]
AND [additional validation points]

### EDGE CASES & ERROR SCENARIOS:
- What happens when requirements aren't met?
- Error handling and user feedback
- Performance degradation scenarios

### DEFINITION OF DONE:
- [ ] Functional requirements met
- [ ] Unit tests written and passing
- [ ] Accessibility tested (WCAG 2.1 AA)
- [ ] Documentation updated
- [ ] Stakeholder sign-off received

### BUSINESS VALUE & METRICS:
- Key metrics this story will impact
- How success will be measured
- Connection to larger business objectives

Ensure each story can be completed within one sprint and provides clear value to the end user.

## Important Guidelines

### Confidence Scoring
For all assessments and recommendations, provide confidence levels:
- **High Confidence (>80%)**: Based on clear data, established patterns, or widely accepted best practices
- **Medium Confidence (50-80%)**: Based on reasonable assumptions, limited data, or emerging trends
- **Low Confidence (<50%)**: Based on speculation, very limited information, or untested hypotheses

### Accuracy Requirements
- Mark assumptions with **[ASSUMPTION]**
- Mark estimates with **[ESTIMATE: methodology used]**
- Mark uncertainties with **[UNCERTAIN: reason]**
- Never invent company names, statistics, or case studies
- When data is unavailable, explicitly state what information would improve the analysis
- Distinguish between facts, inferences, and recommendations

### Source Attribution
- General knowledge: "Based on industry standards..."
- Inferences: "This suggests that..."
- Speculation: "One possibility is..."
- Best practices: "Common approaches include..."

What Makes a Good User Story

• Clearly expresses user value with a real outcome (the So that… isn't fluff).
• INVEST friendly: Independent, Negotiable, Valuable, Estimable, Small, Testable.
• BDD acceptance criteria: GIVEN / WHEN / THEN that an engineer can actually automate.
• Sliceable in one sprint without heroics; avoids hidden epics posing as stories.
• Notes non-functional needs (perf, accessibility, security) where they change the work.

Common User Story Mistakes to Avoid

• Writing requirements or specs and calling them stories.
• Vague acceptance criteria like “works as expected”. Expected by whom?
• Over-stuffing: multiple outcomes jammed into one ticket (hidden epic).
• Solutioning in the story (“use Kafka”, “build with Redis”) without context.
• Ignoring edge cases and error handling until QA finds them in Prod.

Questions PMs Actually Ask (User Stories Edition)

Okay, how detailed should acceptance criteria be before sprint planning?

Detailed enough that an engineer can write an automated test without asking you what “done” means. 3–6 GIVEN/WHEN/THEN lines usually nails it. If you need 12+, you're probably holding an epic.

What's the difference between a user story and a requirement doc?

Stories describe user value and behavior; requirement docs describe comprehensive scope. If your story needs pages of context, promote it to an epic + spec. Your future self will thank you.

How do I split a huge story without losing context?

Slice by outcome, not UI screens. Start with the smallest end‑to‑end value: one persona, one path, one data shape. Keep a parent epic to hold the bigger goal and non-negotiables.

Should I include technical implementation in the story?

Only when constraints change the solution (e.g., “must be offline-capable”, “P95 < 200ms”). Otherwise describe behavior and acceptance. Engineers decide how.

How many stories can we take next sprint given our velocity?

Use median/P85 velocity, not last sprint's best day ever. If you average 24 points with a P85 of 20, plan ~20 and leave slack for bugs and review. Over‑commitment is how carryover becomes a lifestyle.

What are “smelly” stories that get rejected in grooming?

No user value, ambiguous outcomes, magic words like “optimize”, or acceptance like “it should be faster”. Bring numbers. “Reduce P95 from 900ms to 300ms” gets respect.

Do non-functional requirements go in the story?

If they materially change the work, yes—capture them as acceptance (perf budgets, a11y, security). If they're global, link to the standard and reference it.

How do I write stories for platform/back-end work?

Reframe the user: “As an internal platform consumer/service…” Define the contract (API, schema, SLAs) and add BDD criteria that a service test can assert. Value is reliability, latency, or cost—not UI.

When should a story become an epic?

If it spans multiple personas, paths, or requires coordination across teams—or it consistently spills into the next sprint—promote it. Epics keep the “why” intact while you ship value slices.

Can I see a good vs bad story (with BDD)?

Bad: “Improve email system.”
Good: “As a project manager, I want overdue task reminders so teams close tasks on time.”
GIVEN a task overdue by 24h • WHEN reminders run • THEN send one email to assignee and log an event • AND skip weekends.

How to Use This Prompt

When to Use

Use this when preparing for backlog refinement or sprint planning. Perfect for slicing epics into sprint‑sized, INVEST‑friendly stories with clear BDD acceptance criteria.