Decompose a PRD into Stories and Clean the Backlog

Workflow area: Specs & Docs · Tier: Foundation · Hands-on time: ~25 minutes

Decomposition is translation, not creation: every story should trace to a PRD section, and every PRD requirement should land in at least one story. That bidirectional property is exactly what models are good at checking and humans are bad at sustaining. The same mechanical rigor, pointed at your existing backlog, finds the three tickets describing one bug and the eighteen-month-old story referencing a feature you killed.

When to use — and when not to

• Use it when a PRD is approved and needs to become ticketsthe traceability links you get for free here pay off every time scope gets challenged mid-quarter.
• Use it for the quarterly backlog groomdedupe and stale-flag passes over 200 tickets is precisely the work humans skip and models don't.
• Use it when inheriting a backloga new-to-you product's ticket pile, clustered and flagged, is a two-hour orientation instead of a two-week one.
• Skip it for sizing and sequencingstory points, dependency order, and sprint allocation belong to the team that ships; AI estimates of engineering effort are folklore.
• Skip auto-closing anythingthe stale pass flags; humans close. A model cannot know that the dusty ticket is the CEO's pet commitment.

The recipe

1. 1.

   Number your PRD sections, then decompose with mandatory traceability. Paste the PRD into Claude or ChatGPT:

   Copy

   Decompose this PRD into epics and user stories.
   
   Rules:
   - Every story cites the PRD section(s) it implements: [PRD §x.y].
   - Story format: title, As-a/I-want/So-that, 2-4 draft acceptance
     criteria, source citation.
   - Slice vertically (thin end-to-end user value), not by layer —
     no "build the API" stories.
   - After the stories, output a COVERAGE TABLE: every PRD section →
     the story IDs that cover it. List uncovered sections as GAPS.
   - List anything you were tempted to add that the PRD does not
     actually specify under NOT IN PRD — do not silently include it.
   
   PRD:
   [PASTE PRD WITH NUMBERED SECTIONS]
   

2. 2.

   Audit the coverage table before reading the stories. Good output looks like:

   Copy

   COVERAGE
   §3.1 Bulk approval flow    → ST-01, ST-02, ST-04
   §3.2 Notification rules    → ST-05
   §4.1 Audit log             → GAP — no story generated
   NOT IN PRD: password-reset changes (implied by §3.1 but never
   specified — confirm before adding)
   

   GAPs are either PRD sections that aren't buildable requirements (fine) or missed scope (fix now, not in sprint 3). NOT IN PRD items go back to the PRD as explicit decisions — this is scope creep caught at birth.

3. 3.

   Rewrite the judgment stories yourself. Most decomposed stories are mechanical and fine. The handful encoding real decisions — what's in the walking skeleton, where the first release cuts — deserve your hand. Vertical slicing choices are strategy in miniature.

4. 4.

   Run the dedupe pass over the destination backlog. Export existing backlog items (ID, title, description) and ask:

   Copy

   Here are new stories [PASTE] and the existing backlog [PASTE CSV].
   1. DUPLICATES/OVERLAPS: new stories that materially overlap an
      existing item — pair them, say why, and recommend merge or
      supersede. Cite both IDs.
   2. Cluster existing items that appear to describe the same
      underlying request in different words.
   Confidence-rank every match; do not force matches.
   

   Review each proposed pair yourself — near-duplicate titles with different scopes are common, and merging them wrongly loses a requirement.

5. 5.

   Run the stale-flag pass, then decide by hand. Ask the model to flag backlog items that reference removed features, superseded decisions (give it your decision log from pb-24 if you have one), or haven't been touched in a year — with a one-line reason each. You then close, archive, or defend each flagged item. Fifteen minutes, and the backlog stops lying about your intentions.

6. 6.

   Import with links intact. Push stories into Jira or Linear with the PRD citation in each description and the epic structure preserved. The citation is what lets an engineer in week 6 read why without archaeology.

Make it yours

• Linear AI / Jira AI native flow: both can draft sub-issues from a document in-context — use them for the mechanical split, but still run the coverage-table and NOT-IN-PRD checks in a general model; authoring assistants optimize for plausible tickets, not for auditing their own coverage.
• Claude Project per product area: keep the current PRD, decision log, and backlog export as project knowledge — dedupe and stale passes become one-line follow-ups, and the model flags conflicts with decisions it can actually see.
• Team scale: make the coverage table a PRD-review artifact — eng leads sign off on the decomposition by reviewing the table, not by re-reading sixty stories.

Quality check

• The coverage table balances both waysevery buildable PRD section has a story; every story has a citation; spot-check three citations to confirm the story actually implements that section.
• No invented scope survivedeverything under NOT IN PRD was explicitly decided, not silently absorbed into tickets.
• Slices are verticala story an end user couldn't notice shipping is a task, not a story; re-slice it.
• Dedupe merges were human-approvedmodels over-match on similar titles; every merge lost you a ticket, so confirm it didn't lose you a requirement.
• Stale closures have ownerseach closed item was closed by a person with a reason, because "AI cleaned the backlog" will not survive the first stakeholder asking where their ticket went.