What this prompt does
This prompt converts a [feature_description] into sprint-ready planning artifacts. It generates an epic with business value, [story_count] user stories in the "As a / I want / so that" format, Given/When/Then acceptance criteria for each, story-point estimates on your [estimation_scale], a dependency-ordered build sequence, technical tasks, a Definition of Done, a risk assessment, and a capacity plan for a team of [team_size] over [sprint_duration], plus stretch goals and API/wireframe sketches.
The structure works because it closes the gap between a vague request and a backlog you can actually start. Acceptance criteria in Given/When/Then form make each story testable, and the dependency ordering tells you what to build first instead of leaving sequencing to chance. Tying [story_count] and points to a real [team_size] and [sprint_duration] keeps the plan honest: it surfaces when the scope simply does not fit the sprint rather than pretending it does.
When to use it
- Kicking off a new feature where the backlog is still a one-line wish.
- Turning stakeholder requirements into testable, estimable stories.
- Sequencing work so dependencies are built before the things that need them.
- Sanity-checking whether a
[feature_description]realistically fits one[sprint_duration]. - Giving a team acceptance criteria and a Definition of Done before code starts.
- Producing API contract and wireframe sketches early to align backend and frontend.
Example output
You get a structured planning document: an epic summary, then [story_count] user stories each with its role/goal/benefit line, a Given/When/Then acceptance-criteria block, a point estimate, and a list of technical tasks. Below that sit a dependency/build-order list, a Definition of Done checklist, a risk table with mitigations, a capacity plan mapped to your team and sprint, stretch goals, and short API contract or wireframe notes per story.
Pro tips
- Make
[feature_description]concrete; "notification preferences with email digest" yields far better stories than "notifications." - Keep
[story_count]aligned with what one[sprint_duration]can hold; padding the count just creates carryover. - Match
[estimation_scale]to what your team already uses (Fibonacci, t-shirt sizes) so estimates plug into your tooling. - Treat the point estimates as a starting conversation for planning poker, not a final commitment.
- Use the dependency order to spot hidden sequencing, then validate it against your own architecture knowledge.
- If the capacity plan shows the scope overflowing
[team_size]and[sprint_duration], cut stories rather than inflating velocity.
