Act as a product manager working with design and QA. Turn [FEATURE OR PROBLEM] into a small, testable set of user stories for [PRIMARY USER] in this product context: [PRODUCT CONTEXT]. The user’s job, trigger, and desired outcome are: [USER NEED]. Constraints, rules, dependencies, and known decisions: [CONSTRAINTS]. First, state any assumption that materially affects scope. Then produce 3–6 stories, split by user value or independently releasable behavior, not by technical layer. Use this exact format for each: Story: As a [specific user], I want [capability] so that [user outcome]. Why it matters: one sentence tied to the stated need. Acceptance criteria: 3–6 Given/When/Then scenarios covering the happy path, validation or permissions, empty or error state, and the relevant boundary condition. Out of scope: one or two explicit exclusions. Questions or dependencies: only if unresolved. Do not write implementation tasks, database schemas, UI pixel specifications, or acceptance criteria that merely repeat the story. Use observable language: a tester must be able to determine pass or fail without guessing. Preserve business rules exactly and never invent compliance, accessibility, performance, or security requirements; flag them as gaps when applicable. Finish with a short “Story map” that orders the stories as minimum viable release, then follow-on value. Self-check that each story has an identifiable user benefit and that no acceptance criterion depends on unstated behavior. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [FEATURE OR PROBLEM] | Describe the requested capability or user problem to address. | Allow account owners to export a monthly usage report as CSV. |
| [PRIMARY USER] | Name the main user segment for this feature. | account owner at a paid workspace |
| [PRODUCT CONTEXT] | Explain the product, current workflow, and relevant screens or systems. | A project-management web app with a Usage page showing seats, projects, storage, and API calls by month. |
| [USER NEED] | Describe the user’s job, trigger, pain point, and desired outcome. | Finance teams ask account owners for monthly usage data at month end; owners need a file they can share without copying values manually. |
| [CONSTRAINTS] | Paste known business rules, permissions, dependencies, decisions, and exclusions. | Only account owners can export. Reports cover one selected calendar month. CSV must match the visible table. Historical data exists from January 2025. No scheduled exports in this release. |
How to use
- Paste the feature context and include known rules before asking for stories.
- Check that each story delivers a user-visible outcome rather than a technical component.
- Walk the Given/When/Then criteria with design and QA to expose missing states or policy decisions.
- Follow up with: “Convert story 2 into a QA test matrix with preconditions, steps, expected result, and priority.”
Variations
Single story
Use this when the scope is already small and you need one polished story.
Write one user story for [USER] who needs to [NEED] in [PRODUCT CONTEXT]. Known rules: [RULES]. Include the user-story sentence, a brief rationale, 5–7 Given/When/Then acceptance criteria, and explicit non-goals. Cover success, invalid input, permission handling, and one realistic boundary condition. Do not prescribe implementation. Check that every criterion is observable and that no rule has been assumed without being supplied.
Epic breakdown
Use this when a large feature needs slicing into valuable releases.
Break this epic into independently valuable user stories: [EPIC]. The primary users are [USERS], and the product constraints are [CONSTRAINTS]. Give a story map with backbone activities, a minimum viable release row, and follow-on releases. For each story, write a user-benefit statement and 2–4 acceptance criteria. Avoid splitting by frontend, backend, or API work. Flag dependencies that prevent independent release and any unknown business rule that needs a product decision.
Bug story
Use this when a defect needs reproduction rules and an acceptance definition.
Turn this reported defect into a bug-focused user story and acceptance criteria. Report: [BUG REPORT]. Product environment and affected users: [CONTEXT]. Expected policy or behavior: [EXPECTED BEHAVIOR]. Produce a concise problem statement, reproducible steps if supported by the report, severity questions, and Given/When/Then criteria for the corrected behavior. Include regression cases near the failure boundary. Do not infer root cause or claim reproduction if evidence is missing; list missing diagnostics instead.
Tips
- Write stories around a user decision or completed job, not around a page, endpoint, or component.
- Make business rules visible in acceptance criteria so QA does not have to recover them from tickets or chat messages.
- Use one boundary condition that is meaningful for the feature, such as permission, date range, duplicate action, or incomplete data.
- Keep non-goals in the ticket when a plausible adjacent feature could otherwise expand scope.
FAQ
How many user stories should one feature create?
Use as many as needed to create independently testable increments, often three to six. A single large story often hides important decisions.
Are acceptance criteria the same as test cases?
They define expected behavior and can inform test cases, but test cases usually add setup, detailed steps, environments, and test data.
Should AI write technical tasks too?
It can suggest them after the product behavior is agreed, but keep user stories and implementation plans separate so scope remains clear.