---
name: roadmap-sequencing
description: Decide the order a prioritised set of roadmap work should be built, so value arrives early, nothing is blocked by an unbuilt prerequisite, and the riskiest bets are tested before the expensive work depends on them. Covers building the dependency graph (hard versus soft, finish-to-start), a topological ordering so prerequisites come first, economic ordering of the unblocked set with CD3 and WSJF (cost of delay divided by duration), front-loading the riskiest assumption, splitting and decoupling to break long dependency chains, a work-in-progress cap with slack, and reverse-scheduling the firmly fixed dates. Use it when someone says sequence the roadmap, what order should we build this in, which should come first, map dependencies, our teams keep blocking each other, or we have a ranked backlog and need an order. Do NOT use it to rank or score which items are worth doing (see prioritisation-frameworks), to choose the roadmap format or communicate it (see product-roadmapping), or to forecast delivery dates probabilistically (see delivery-forecasting).
license: CC BY 4.0. Free to use and adapt with credit to Afeez Adebayo, linking afeezadebayo.com, his LinkedIn (https://www.linkedin.com/in/afeez-adebayo/) and the skill's download page.
---

# Roadmap sequencing

Prioritisation decides what is worth building. Sequencing decides the order you actually build it in, and the two are not the same job. A perfectly ranked backlog still fails if the top item cannot start until a prerequisite three places down is finished, if the whole quarter is spent on an idea whose core assumption was never tested, or if two teams sit idle waiting on each other. This skill makes an AI agent turn a ranked list into a buildable order: prerequisites first, then the highest economic urgency among the work that can actually start, with the riskiest assumptions pulled forward and long dependency chains broken rather than endured. It orders the work; it does not rank it, format it, or date it. Ranking is the prioritisation-frameworks skill, roadmap format is product-roadmapping, and probabilistic dates are delivery-forecasting.

## When to use this skill, and when not to

Use it when someone has a prioritised or roughly ranked set of initiatives, epics or features and needs to decide the order of delivery. Use it when someone says sequence the roadmap, what should we build first, map the dependencies, our teams keep blocking each other, we committed to a date and need to work backwards, or we have the priorities but the plan keeps stalling on prerequisites.

Do not use it to decide which items are worth doing or to produce their rank order; that is the prioritisation-frameworks skill, and a good sequence starts from its output. Do not use it to choose how the roadmap is drawn or communicated, Now-Next-Later versus timeline versus theme; that is product-roadmapping. Do not use it to produce a probabilistic delivery date or a confidence range; that is delivery-forecasting, which this skill hands off to once the order is set. Do not use it to slice a single feature into releases around one user journey; that is user-story-mapping.

## What the agent must have before starting

Ask for whatever is missing, and never invent a dependency, a date, or a cost of delay:

1. The prioritised candidate work, with each item's relative value and a rough size or duration. If the list is not yet ranked, stop and send it to prioritisation-frameworks first; sequencing an unranked pile produces a plausible order with no economic basis.
2. The dependencies between items: what must exist before what can start. Capture whether each one is a hard dependency (the work truly cannot begin or ship without it) or a soft dependency (it would be easier, cleaner or faster, but is not strictly required). This distinction decides most of the sequence.
3. Team capacity and the shape of the teams: how many parallel streams of work can run at once, and which teams own which items. You cannot sequence for flow without knowing how much can be in flight.
4. The riskiest assumption behind each large item: the single belief that, if wrong, kills the item. This is what gets pulled forward.
5. Any firmly fixed dates: a contractual deadline, a regulatory date, a dependency on an external party, a launch tied to an event. Everything else is a consequence of the sequence, not an input to it.

If someone hands you a ranked list with no dependencies and asks for an order, the first move is to elicit the dependencies item by item, because a ranking plus no dependency map almost always hides a prerequisite that will reorder the plan.

## The workflow

### Step 1: Build the dependency graph

List every item as a node. For each pair, ask one question: can this item start and ship without that one being done first? If no, draw a directed edge from the prerequisite to the dependent item, and tag it hard or soft. Record the type of each hard dependency, because it changes the sequence: finish-to-start (B cannot start until A finishes) is the strict case; start-to-start (B can start once A has started) and finish-to-finish (B cannot finish until A finishes) allow overlap and should be exploited later. Capture cross-team dependencies explicitly, with the owning team on each node, because a dependency that crosses a team boundary carries a hand-off and a queue, and hand-offs are where roadmaps lose weeks.

The output of this step is a graph, not a list. If drawing it reveals a cycle (A needs B, B needs A), the cycle must be broken before any order exists; that is a decoupling problem, handled in Step 5.

### Step 2: Order so no prerequisite comes after its dependant

Produce a topological order of the hard-dependency graph: every item appears after all of its hard prerequisites. This is the skeleton of the sequence and it is non-negotiable; an order that violates it is not a plan, it is a wish. Soft dependencies do not constrain this step; they are tie-breakers and overlap hints, not walls.

Identify the critical path: the longest chain of hard dependencies through the graph. Its length is the floor on how fast the whole set can be delivered no matter how many people you add, so it is the first thing to attack if the timeline is too long. Work off the critical path can run in parallel and should be scheduled to fill the time the critical path takes, not to extend it.

### Step 3: Order the unblocked set by economic urgency

At any point in the sequence, several items may have all their prerequisites met and be ready to start. Choose among them by cost of delay per unit of duration, not by raw rank. The rule from lean product development is weighted shortest job first, also written as CD3 (cost of delay divided by duration):

WSJF = cost of delay / job duration (use job size as a proxy for duration when duration is hard to estimate).

Score cost of delay as the sum of three relative components, each on a modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20) with the smallest item in each column set to 1: user and business value, time criticality, and risk reduction or opportunity enablement. Divide the sum by the item's size on the same scale. The highest WSJF among the ready items goes next. This is what makes a small, urgent, enabling item beat a large, valuable, but patient one: delivering the short high-value job first loses the least total value to delay. Re-score only the remaining work as the sequence advances, so sunk cost never influences the next choice.

Cost of delay is a relative estimate, not a measured figure. Label it as an estimate, state the three component scores, and never present a WSJF number as if it were money unless the business has supplied real per-week figures (as in the Maersk Line case, where one feature's cost of delay was estimated at more than 200,000 US dollars per week).

### Step 4: Front-load the riskiest assumption

Within the economic order, pull the cheapest risk-reducing work forward. For each large item, the riskiest assumption is the belief that would kill it if false. Sequence a small, cheap test of that assumption, a spike, a prototype, a fake-door test, a technical proof of concept, before the expensive build that depends on it. The reason is asymmetry: a dead hypothesis found in week one costs a week, and the same hypothesis found in month three costs a quarter plus everything built on top of it. This is the one case where you deliberately sequence a low-WSJF item early, because its value is the option it preserves, not the feature it ships. Tie every item to an outcome so that when a test kills an assumption, the dependent work can be dropped without the plan collapsing.

### Step 5: Break long chains by splitting and decoupling

A long critical path and deep dependency chains are the main cause of a roadmap that cannot move. Two levers shorten them. First, split: any item larger than roughly six to eight weeks is split into smaller items that can be sequenced and started independently; an unsplit large item hides internal dependencies and blocks everything behind it. Second, decouple: where one item waits on another only for an interface or data, remove the wait rather than the work. Concrete decoupling tactics are a contract-first interface (agree the API shape, then both sides build against it in parallel), a stub or mock (the dependent team builds against a fake until the real thing lands), a feature flag (ship the dependent code dark and switch it on when the prerequisite is ready), and a vertical slice (deliver one thin end-to-end path through several components rather than each component in full before any integrates). As a rule of thumb, if a hard-dependency chain is more than three links deep, treat shortening it as a design task before accepting the sequence, and break any cycle in the graph with one of these tactics so a topological order exists at all.

### Step 6: Respect capacity and leave slack

Lay the ordered items onto the available parallel streams, never scheduling more concurrent work than the teams can actually carry. Limiting work in progress is what keeps the sequence flowing: starting more work when things are already in flight lengthens everything and delivers nothing sooner. Do not plan to one hundred per cent of capacity. Leave slack, around twenty per cent as a starting point, because slack absorbs the unplanned work, the rework and the cross-team hand-offs that are not on the plan yet. A sequence with no slack is a sequence that breaks on contact with the first surprise.

### Step 7: Place the fixed dates and work backwards

For each firmly fixed date, schedule its item and its entire hard-dependency chain backwards from the deadline, adding a buffer for the chain's uncertainty rather than assuming each link lands on its expected day. If the backwards schedule collides with the critical path or with capacity, that is the finding: either the date is at risk, or scope must be cut, or a dependency must be decoupled to shorten the chain. Surface the collision now; do not bury it by compressing estimates. Dates for everything that is not firmly fixed are an output of the sequence and belong in delivery-forecasting, not here. Committing a sequenced plan with dates to stakeholders is a promise, so present the sequence as a proposal and leave the commitment to a person.

## Worked example

Input: a growth-stage team with a ranked set of five epics and two teams (Platform, App). Ranked: 1. Self-serve checkout, 2. Usage-based billing, 3. Enterprise SSO, 4. In-app upsell prompts, 5. Admin audit log. Two fixed dates: SSO is tied to two signed contracts due in ten weeks; the audit log is a SOC 2 requirement due at the audit in sixteen weeks.

Step 1 and 2 surface the real graph. Usage-based billing (App) hard-depends on a metering service (Platform) that is not yet on the list; it is added as a prerequisite. Self-serve checkout hard-depends on the billing integration. In-app upsell soft-depends on checkout (nicer with it, not blocked by it). SSO and the audit log are independent of the rest. The critical path is metering then billing then checkout, three links deep, and it is longer than the naive rank implied.

Step 3 orders the ready set. At the start, metering, SSO and the audit log are all unblocked. SSO has the highest WSJF: high business value (signed contracts), high time criticality (a ten-week date), and small size, so it goes first on Platform while metering also starts. Checkout, ranked first, cannot start yet because its prerequisites are not done; its rank did not change, its position did.

Step 4 pulls risk forward: usage-based billing rests on the assumption that customers will accept metered pricing, so a one-week pricing-validation spike is sequenced before the billing build, not after it.

Step 5 shortens the chain. Checkout and billing are decoupled with a contract-first billing interface so the App team builds checkout against the agreed contract while Platform finishes metering, turning a three-link wait into two parallel streams. Step 6 caps each team at two concurrent epics and leaves one stream of slack for the SOC 2 work that always grows. Step 7 schedules the audit log backwards from the sixteen-week audit with a two-week buffer. The result is an order where the two dated commitments are protected, the longest chain is broken into parallel work, and the riskiest pricing bet is tested for one week before a quarter is spent on it.

## Templates you can use verbatim

Dependency entry: "[Item B] depends on [Item A] | type: hard/soft | relationship: finish-to-start/start-to-start/finish-to-finish | crosses team boundary: yes/no | reason: [one line]."

WSJF scoring row: "[Item] | user/business value: _ | time criticality: _ | risk reduction/opportunity: _ | cost of delay (sum): _ | size: _ | WSJF (CoD/size): _ | all prerequisites met: yes/no."

Decoupling decision: "[Item B] waits on [Item A] for [interface/data/capability]. Decouple by: contract-first interface / stub or mock / feature flag / vertical slice. Owner of the contract: [team]. Parallel from: [date/sprint]."

Fixed-date check: "[Date] is fixed because [contract/regulation/external/event]. Dependency chain to it: [A to B to C]. Backwards schedule with buffer: [start-by date]. Collision with critical path or capacity: yes/no. If yes: [cut scope / decouple / flag the date at risk]."

Sequencing summary to stakeholders: "Proposed order and why: prerequisites first, then highest cost-of-delay-per-size among what can start, riskiest assumptions tested early. Two commitments carry dates: [X] and [Y]. Everything else is direction; firm dates come from a separate delivery forecast. This is a proposal for your sign-off, not a committed schedule."

## Failure modes and anti-patterns

1. **Sequencing by rank alone.** The order copies the priority list, ignoring that the top item is blocked by a prerequisite further down. Spot it: the first item cannot actually start today. Fix it: build the dependency graph and topologically order it before reading the ranks.
2. **Invisible cross-team dependencies.** Each team's slice looks fine alone, but one waits on another's hand-off that no one scheduled. Spot it: a team goes idle mid-quarter, or an item sits in "ready" for weeks. Fix it: tag every dependency that crosses a team boundary in Step 1 and decouple the ones on the critical path.
3. **The unbroken chain.** A four or five link hard-dependency chain is accepted as given, so the critical path is the whole timeline and nothing can be parallelised. Spot it: the critical path length equals the total plan length. Fix it: split large items and decouple with contracts, stubs or flags until the chain is three links or fewer.
4. **Risk deferred to the end.** The expensive build is sequenced first and the assumption test last, so a dead hypothesis is found after a quarter of work depends on it. Spot it: no spike, prototype or validation appears before a large bet. Fix it: front-load the cheapest test of each big item's riskiest assumption.
5. **Dates squeezed to fit.** A fixed date collides with the critical path, so estimates are quietly compressed until the plan "fits". Spot it: the backwards schedule only works if every link lands on its best-case day. Fix it: surface the collision, buffer the chain, and cut scope or decouple rather than pretending the date is safe.

## Quality bar

Before handing over a sequence, confirm: every item appears after all of its hard prerequisites and the order contains no cycle; the critical path is identified and is three links or fewer, or the longer chain is justified; among items that can start at each point, the next one chosen has the highest cost of delay per size, with the three component scores shown and labelled as estimates; each large item has its riskiest assumption tested by a cheap step sequenced before the expensive build; large items are split to roughly six to eight weeks and long chains are decoupled with a named tactic and a named owner; concurrent work does not exceed capacity and around twenty per cent slack remains; each firmly fixed date has a backwards schedule with a buffer and any collision is surfaced, not hidden; and the whole thing is presented as a proposal for human sign-off, with any committed dates marked as the only promises and all other dates deferred to delivery-forecasting. No dependency, date or cost-of-delay figure in the output is invented; each traces to something the team supplied.

## Tool appendix

- **Jira Plans (Advanced Roadmaps), Aha! Roadmaps, Productboard**: all model dependencies and let you reorder before committing. Use the dependency map or program-board view to find cross-team links and the critical path, and set alerts for past-due dependencies and stalled work where the tool supports it. Record a dependency when you create the work, not after it blocks something.
- **Design structure matrix (DSM) tools**: for a dense dependency set, a DSM (an N by N matrix with items on both axes and a mark where one depends on another) makes cycles and clusters visible and supports re-sequencing to minimise feedback loops; useful when a simple graph becomes unreadable.
- **A whiteboard or a slide**: often the best place to agree the sequence with stakeholders, because moving cards forces the dependency and capacity conversation that a Gantt chart hides. Export the agreed order to the tracker afterwards.
- No tool decides cost of delay, the riskiest assumption, or whether a dependency is hard or soft; those are judgement calls the tool only records. A tool that auto-schedules from ticket estimates will happily produce a critical path no one chose.

## Sources

- Scaled Agile Framework, "WSJF" (cost of delay, the three components, WSJF = CoD / job size, sequencing by highest WSJF, splitting large jobs). scaledagileframework.com. Last verified 11 November 2026.
- Joshua Arnold / Black Swan Farming, "Cost of Delay" and CD3 (cost of delay divided by duration; the Maersk Line example at more than 200,000 US dollars per week). blackswanfarming.com/cost-of-delay. Last verified 11 November 2026.
- Uxcel, "Dependency mapping and sequencing" (dependency types, mapping the real order of work, critical path, parallelisable work, buffering where hand-offs are many). app.uxcel.com. Last verified 11 November 2026.
- Aha!, "Manage cross-team dependencies" (record dependencies as you plan, dependency maps, reorder on a whiteboard before committing, alerts for past-due dependencies). aha.io/roadmaps/dependencies. Last verified 11 November 2026.
- Bent Flyvbjerg and Alexander Budzier, "Why Your IT Project May Be Riskier Than You Think", Harvard Business Review, 2011 (1,471 projects; one in six a black swan with 200 per cent average cost and almost 70 per cent schedule overrun; break large projects into limited-size pieces). arxiv.org/abs/1304.0265. Last verified 11 November 2026.
- Donald Reinertsen, "The Principles of Product Development Flow" (cost of delay, limiting work in progress, economic sequencing), as applied in the sources above. Last verified 11 November 2026.
- Marty Cagan / SVPG and Teresa Torres on testing the riskiest assumption before building (front-loading the cheap validation). Last verified 11 November 2026.

---
1.0.0, 11 November 2026: first release. Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo, link afeezadebayo.com and the skill's download page. This is decision-support guidance, not a substitute for your own product and engineering judgement.