PRD-08 · SEC. 04 Product & Planning

Order Features by Dependency Before Sequencing the Roadmap

Turn a flat feature list into a dependency-ordered build sequence before assigning sprints.

FORMAT: workflow
DIFFICULTY: intermediate
TIME: 20 min
TOOLS: universal
MODELS: any
COPIES: 0 so far

When to use this

You have an approved feature list or backlog and you're about to assign it to sprints or tickets in the order it was written down, which is usually the order people thought of it in, not the order it can actually be built in.

The pattern

Pastes as plain text

Map the dependencies in the feature list I give you.

For each feature, identify:
1. What it depends on (other features on this list, or "none")
2. What depends on it (downstream features that can't start until this ships, or "none")
3. Whether it's a leaf (no dependencies, buildable immediately), composite (depends on other features here), or integration (touches multiple other features/systems)

Then output a build order: leaves first, grouped by what unlocks the most downstream work, integration features last. Flag any circular dependency you find, that's a scoping bug, not something to sequence around. Stop there and wait for my review.

Once I approve the order, convert it into numbered phases, each phase only containing features with no unresolved dependencies from earlier phases. Note which phases can run in parallel across different people/agents versus which must be sequential.

Start by asking me for the feature list: either paste it or name the file in this repo that holds it. Wait for my reply before mapping anything.

Real example output

"LEAVES: user auth (none), receipt upload (none), category taxonomy (none).
COMPOSITE: expense categorization (depends on: receipt upload, category taxonomy), monthly report (depends on: expense categorization).
INTEGRATION: partner API export (depends on: expense categorization, auth; needs API-key scoping across both).

No circular dependencies found.

PHASE 1 (parallel): user auth, receipt upload, category taxonomy.
PHASE 2 (sequential, needs Phase 1 complete): expense categorization.
PHASE 3 (parallel): monthly report, partner API export; both only need categorization, not each other."

Why it works

Naming leaf/composite/integration forces an explicit dependency graph instead of an implicit one, so "build this first" decisions come from what's actually blocking what, not from the order items appear in a meeting note. The circular-dependency flag catches a real scoping bug before it becomes a stuck sprint.

Related patterns

ENG-10Leaf-to-Root Build OrderBuild UI leaf-first: components, then composites, then pages, routing, state, and API.PRD-13Turn an Approved Spec into Engineering-Ready TicketsSplit a locked spec into sized tickets with acceptance criteria instead of one vague epic.PRD-10Recalibrate the Roadmap as Actuals LandLog estimate vs actual per finished ticket, compute a drift factor, and re-plan when the milestone math breaks.