# Prd To Sprints

> Turns a PRD, design doc, or feature spec into a Scrum-style product backlog broken into ≤4-hour tasks (1 story point = 4 hours), grouped into 6-day sprints capped at 12 points, with dependencies tracked and a Definition-of-Done check that the product stays in a shippable state at the end of every sprint and every epic - never saving all the "wire it into production" work for one big integration epic at the end. Use this whenever the user shares or references a PRD, spec, design doc, or feature description and wants it turned into tasks, a backlog, a sprint plan, story points, or an estimate of how long something will take to build - even if they don't say "Scrum" or "sprint" explicitly, e.g. "break this down into tasks," "how should we sequence this project," "plan out this feature," or "how many sprints will this take."

- Skill: `ukkit/prd-to-sprints` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add ukkit/prd-to-sprints`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ukkit/prd-to-sprints/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ukkit (https://skillmd.com/u/ukkit)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ukkit/prd-to-sprints

---


# PRD to Sprints

Converts a PRD/design document into a Scrum backlog: small tasks sized in 4-hour story points, sequenced by dependency, and grouped into 6-day sprints (12-point capacity per sprint for one contributor), each ending in a checked, shippable increment. Shippability is enforced at both levels that matter - every sprint, and every epic - so the product is never left in a state where several epics' worth of work has landed but nothing is actually live or demoable yet.

Read `references/scrum-principles.md` before grouping tasks into sprints - it explains *why* a Sprint Goal and Definition of Done matter here, not just what to put in them. Read `references/story-splitting.md` before sizing tasks - it has the INVEST/SPIDR techniques for cutting a feature down to ≤4-hour pieces without producing pieces that are individually useless.

## Workflow

### 1. Get the source material and the missing parameters

You need the PRD/design doc itself (a file path, pasted text, or a doc link the user gives you - read the whole thing, don't work from a summary). You also need two numbers that change the whole plan, so don't silently assume them if the PRD doesn't say:

- **Team size / parallelism.** Default is **one contributor**, so a sprint holds 12  points total. If the user mentions a team, ask how many people can work in  parallel - sprint capacity scales linearly (e.g., 3 people ≈ 36 points/sprint),  but dependent tasks still can't be parallelized just because there's headcount.
- **Anything the PRD leaves genuinely ambiguous** that would change task sizing or  ordering - vague acceptance criteria, an unspecified tech stack where the choice  affects effort, a feature that references an external team/API with unknown  turnaround. Don't guess and move on for these; ask. Do NOT ask about things you  can reasonably infer or that don't change the plan - over-asking is as unhelpful  as under-asking.

### 2. Extract the Product Goal and epics

State the Product Goal in one or two sentences - the outcome the PRD serves. Then pull out the epics/features as the PRD organizes them. This becomes the top level of the Product Backlog.

### 3. Break epics into ≤4-hour tasks

Work epic by epic. For each, split into tasks small enough to estimate at 1 point (4 hours) using the techniques in `references/story-splitting.md`. Per Scrum's own practice, don't spend equal effort on every epic: fully decompose the epics that will land in the first couple of sprints, and leave epics you expect much later as coarser, unsplit items you flag as "to be refined closer to the sprint" - trying to produce perfectly-sized 4-hour tasks for a feature that's 8 sprints out just produces estimates you'll have to throw away once assumptions change.

Every task needs:
- A short title and a one-line description of the outcome (not implementation steps)
- An estimate in points (should almost always be `1`; only ever `>1` for the  genuinely-atomic case in story-splitting.md, and never `>3` - if you're about to write 4, split it instead)
- A dependency list: IDs of other tasks that must complete first (empty if none)
- A one-line "how you'd verify this is done" note - this is what makes it testable,  and what the sprint's Definition of Done will check against later

**Watch for a "build it" epic paired with a "wire it live" epic.** Many technical PRDs (a calculation engine, a batch pipeline, an internal service with several independent capabilities) naturally split into core-capability epics - the actual logic - and a separate layer that makes that logic actually run: a cron job, a daily/batch integration, an API surface. The default failure mode is to build every core-capability epic first and cluster all of the "make it live" work into one integration epic at the very end. That means nothing the PRD describes is actually
*shippable* - per `references/scrum-principles.md`'s definition, technically releasable - until the very last sprint, no matter how many sprints of correct, tested code came before it. It also means if the project stops early (reprioritized, descoped, the usual), everything built so far is inert.

When you spot this shape, slice the other way: build the live-integration plumbing once, alongside the *first* core-capability epic that needs it, then have each subsequent core-capability epic *extend* that existing plumbing with its own piece (a bigger batched query, one more wired-in case) instead of waiting for a final integration pass. Concretely:
- The first capability epic gets the full cost of building the plumbing (the job  hook, the upsert/write path, any scoping logic) *plus* wiring its own piece in.
- Every later capability epic gets a much smaller "extend the existing wiring"  task instead of its own separate integration epic.
- This almost always costs a little more total effort than one big integration  pass at the end (you touch the same wiring code more than once). Say so explicitly in the plan's Risks section - ideally quantified in points - so the  tradeoff is visible, not silent. In exchange, the product is genuinely live and  demoable after every capability epic, not just the last one.

This doesn't apply to every PRD. A feature that's already naturally vertical (each epic is already user-facing end to end, e.g. most UI features) doesn't need this it only matters when several capability epics share a piece of plumbing that would otherwise become its own late-stage "integration epic."

### 4. Sequence by dependency, then group into sprints

Topologically order tasks so nothing is scheduled before its dependencies. Within what the dependency graph allows, prioritize by the order/value the PRD implies.

Fill sprints to the point capacity (12 × team size) **but treat that as a ceiling, not a target** - per `references/scrum-principles.md`, a sprint that ends on a coherent, demoable slice at 10-11 points beats one that hits 12 by cutting a feature in half. When a task would be the one to push a sprint over capacity, and it's not splittable further, move the whole task to the next sprint rather than starting it.

Give every sprint a **Sprint Goal**: one sentence describing what becomes true/usable once the sprint ends. If you can't write one sentence that covers everything you put in the sprint, the grouping needs rework - regroup by feature/user-value rather than just by point-count-until-full.

### 5. Check each sprint - and each epic - ends shippable

Before finalizing a sprint, verify:
- Every task in the sprint has all its dependencies satisfied by this sprint or earlier ones (never a forward reference).
- The sprint's tasks combine into something a stakeholder could actually look at or use - not three unrelated fragments of three different features. If they don't, re-group (pull in a small task from later to complete a slice, or push out a task that doesn't fit this sprint's story, even if that leaves the sprint under 12 points).
- Write a **Definition of Done** checklist specific to that sprint's actual content (see the elements listed in scrum-principles.md) - not a generic copy-pasted  checklist. If the sprint includes a UI change, the DoD should say so explicitly;  if it's pure backend, don't include a UI review line.

Separately, check this at the **epic** level too, once you've grouped sprints: walk each epic and confirm that by the sprint where it completes, its capability is actually running/usable, not merely built-and-tested-in-isolation. If an epic completes but its output only becomes real once some *later* epic's integration work lands, that's the "build it" / "wire it live" split from Step 3 - go back and pull a slice of the live-integration work into this epic instead of leaving it stranded. A sprint's shippable-increment statement should describe what's actually running in production when the PRD has a live component (a job, a service, an API) - not just "the calculation logic is correct," which is a necessary but weaker claim.

### 6. Write the plan

Produce a single Markdown document with this structure:

```markdown
# [Product Goal - one or two sentences]

## Product Backlog
| ID | Epic | Task | Points | Depends On |
|----|------|------|--------|------------|
| T1 | ...  | ...  | 1      | -          |

(Group by epic; note which epics are fully refined vs. left coarse for later.)

## Sprint 1 - [Sprint Goal, one sentence]
**Duration:** 6 days · **Capacity:** 12 points · **Committed:** [N] points

| ID | Task | Points | Depends On | Verify by |
|----|------|--------|------------|-----------|
| T1 | ...  | 1      | -          | ...       |

**Definition of Done for this sprint:**
- [ ] ...tailored checklist...

**Shippable increment:** [one line on what a user/stakeholder can actually see or use once this sprint's DoD is met]

## Sprint 2 - ...
(repeat)

## Risks / open questions
(anything flagged during breakdown: external dependencies, ambiguous requirements resolved by assumption, epics left coarse)
```

If the user asked for JSON/CSV alongside the markdown, also emit a flat task list (id, title, points, depends_on, sprint) in that format as a second file - keep the markdown as the primary, human-readable artifact either way.

## Common mistakes to avoid

- **Don't pad estimates instead of splitting.** If a task feels like 6-8 hours,  it's two tasks, not one 2-point task - see story-splitting.md's SPIDR patterns.
- **Don't chase exactly 12 points.** It's a ceiling; coherence beats the number.
- **Don't split by technical layer by default** (DB/API/UI/tests as four "tasks"  for one feature) - it produces pieces that can't be verified independently and  almost always end up as cross-sprint dependencies that break shippability.
- **Don't invent task owners/assignees** unless the user gives you real names or  roles - Scrum teams self-manage this, and it's not this skill's job to guess.
- **Don't over-refine distant epics.** Full 4-hour decomposition is for the next  sprint or two; further out, coarser is honest and cheaper to redo.
- **Don't cluster all "wire it into production" work into one epic at the end**  when several capability epics share it. Build the plumbing once, attached to the  first capability that needs it, and have every later capability extend it - see  Step 3. A plan where nothing is genuinely live until the final epic has failed  the shippability requirement even if every individual sprint's DoD passed.