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 paste below the line.

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.

Paste the feature list below this line:

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.