Epic Decomposition: Vague Epic to Sequenced, Estimable Tickets

Tier: Foundation · Workflow area: Planning & Collaboration

This playbook uses AI as a decomposition assistant, not a planner: the model proposes tickets, dependencies, and risk flags; you own the sequencing, the estimates, and the plan. The payoff is coverage — the model reliably surfaces the migration step, the rollout gate, and the monitoring ticket you would have remembered in sprint 3.

When to use

• •
  You own an epic that spans multiple services, multiple sprints, or multiple people.
• •
  The epic description is one paragraph of product language and you need engineering-shaped tickets by tomorrow's refinement.
• •
  You inherited an epic mid-flight and need to check the existing breakdown for gaps.

Skip AI for single-ticket features or work you have shipped five times before — your own template is faster and already calibrated to your team.

Prerequisites

• •
  Any capable chat assistant (Claude, ChatGPT, Copilot Chat) — no API access required.
• •
  The epic description, acceptance criteria, and any design doc or API contract you already have.
• •
  5 minutes of your own context notes: affected services, known constraints (compliance, freeze windows), team size.

The workflow

1. 1.

   Write the context block yourself (5 minutes). The quality of the decomposition is capped by what the model knows. Paste: the epic text, the services it touches, the tech stack, any hard constraints ("payments-service is frozen until the PCI audit", "two engineers, one on-call"), and the definition of done.

2. 2.

   Request a structured decomposition with rules.

   Copy

   Decompose this epic into engineering tickets.
   
   Rules:
   - Each ticket: title, 2-4 sentence description, acceptance criteria,
     affected services/files, estimate bucket (S/M/L — NOT hours),
     dependencies (ticket IDs), and a risk flag (none/low/high + why).
   - Sequence tickets so nothing depends on unfinished work.
   - Separate: schema/migration work, feature code, tests, rollout
     (flags, gradual release), observability (metrics, alerts, dashboards),
     and docs/runbook updates as distinct tickets where they exist.
   - Mark any ticket that requires a decision I have not made yet as
     BLOCKED-ON-DECISION and state the decision needed.
   - Do not invent requirements. If scope is ambiguous, list the
     ambiguity under "Open questions" instead of resolving it.
   

3. 3.

   Run the gap attack. In the same conversation: "Now attack this plan. What is missing? Check specifically: data backfill, backward compatibility, feature-flag cleanup, load/perf validation, error budgets, on-call handoff, and anything a senior reviewer would flag." Expect it to find 2–4 real gaps — that is the main value of the exercise.

4. 4.

   Re-sequence and estimate yourself. Convert S/M/L buckets to your team's points using your velocity, not the model's. Reorder for parallelism across your actual people. Delete tickets that gold-plate.

5. 5.

   Paste into your tracker and mark provenance. Note in the epic that the breakdown was AI-assisted and human-reviewed — this matters for the team norms in pb-43.

Tool variants

• Chat assistant (Claude / ChatGPT): the default; long context handles a full design doc pasted alongside the epic.
• Copilot Chat in the IDE with the repo open: better file-level accuracy in "affected services/files" because it can see the codebase; weaker at rollout/ops tickets.
• Issue-tracker AI (Jira AI, Linear): convenient for direct ticket creation, but run the gap attack in a real chat first — tracker assistants rarely support adversarial follow-ups.

Verification

• •
  Every ticket's dependency list references tickets that actually exist in the output — no dangling IDs.
• •
  The gap attack in step 3 produced at least one item you agree was genuinely missing; if it produced zero, your context block was too thin — add constraints and rerun.
• •
  Each BLOCKED-ON-DECISION item maps to a real open decision; resolve or assign each before refinement.
• •
  Cross-check "affected services" against the codebase for at least the three largest tickets.

Pitfalls

• Accepting hour estimates. Models produce confident, uncalibrated numbers. Buckets only; you convert.
• One-shot decomposition. The first pass is a draft. Steps 3–4 are where the plan becomes yours; skipping them is delegation, not assistance.
• Missing the invisible tickets. If the output has no migration, rollout, or observability tickets, it did not follow the rules — reprompt; do not assume they are not needed.
• Pasting confidential roadmap context into an unsanctioned tool. Epics often contain unreleased product plans — use your approved tool.

Restricted-environment variant

For client engagements where epic content is under NDA:

• •
  Strip client names, product codenames, and financial context; describe services generically (billing-svc, CLIENT_A portal).
• •
  Use the client-approved enterprise tenant (Copilot Business, Azure OpenAI, Bedrock in the client's account) when one exists — decomposition needs no code, so data-policy exposure is limited to the epic text itself.
• •
  Fully offline: a local model (Ollama + a current 8B–30B instruct model) handles step 2 acceptably; keep the gap-attack checklist as a manual checklist since small models miss more.

Success criteria

• •
  A refinement-ready breakdown in under 30 minutes for an epic that normally takes half a day to decompose.
• •
  At least one genuine gap caught before sprint start that would otherwise have surfaced mid-sprint.
• •
  Dependencies explicit enough that two engineers can work the epic in parallel without stepping on each other.
• •
  You can defend every ticket, sequence choice, and estimate in refinement without referencing "the AI said".