# Roadmapping & Prioritisation

Turns an agreed scope into a sequence — what ships first, what waits, and the reasoning that put each item where it is.

## Deliverable

One Markdown document, `release-plan.md`, in the structure set out under **Output** below. It takes the output of **Product Discovery & Scoping** and feeds **Estimation & Risk Planning**.

## Required inputs

- **A scope list** — the items to sequence. Section 6 of `scope-definition.md` is the expected form; any list whose items are separately shippable will do.
- **The outcome the work is measured against** — the objective the order is optimising for.

Without both, stop. A sequence with nothing to optimise for is an opinion with numbers on it.

## Optional inputs

- Effort figures from the people who would do the work
- Fixed external dates: contracts, seasons, regulatory deadlines, campaigns
- Team composition and availability
- Known dependencies: systems, vendors, approvals, data migrations
- Stakeholder preferences, each attributed to the stakeholder who holds it

Value and effort are never invented. Where a figure is missing, the plan orders on the dimensions that are known and records the item as `unscored`.

## Execution

**1 — Normalise the items.** One line per item, each separately shippable. Split anything that cannot ship alone, and record the split so every piece traces back to the scope it came from.

**2 — Map the dependencies.** For each item: what must exist before it can start, and who owns that thing. Mark every dependency `internal` or `external`. External ones — a vendor, an approval, another team — are listed by name, because they set the real critical path.

**3 — Score what can be scored.** Value is the outcome the item moves, taken from the input rather than from how strongly it is wanted. Effort comes only from the people who would do the work. An item missing either figure is marked `unscored` and carried forward; it is not given a number to make the list look complete.

**4 — Place risk first.** Identify the items that would invalidate the plan if their assumption turns out wrong. Schedule them into the earliest release that can carry them, ahead of higher-scoring but safer work, and write the reason next to them.

**5 — Group into releases.** Each release must be useful on its own. A group that only pays off once a later group lands is a milestone, not a release, and is labelled as one.

**6 — Record the trade-offs.** For each release: what was displaced to make room, who agreed, and when. Without this section a sequence cannot be reviewed, only argued about.

**7 — Set the re-cut triggers.** For each deferred item, the specific condition that would bring it forward. For the plan as a whole, the facts whose change would reorder it.

## Output

`release-plan.md`, in this order:

- **1. Input and date** — which scope this plan sequences, and when
- **2. Releases** — per release: name, what it is for, the items in it, and whether it is independently useful
- **3. Dependency map** — one line per dependency: item, what it needs, owner, `internal` or `external`
- **4. Critical path** — the ordered chain that sets the earliest finish, with external links marked
- **5. Prioritisation** — one line per item: value, effort, placement, and the reason; `unscored` items listed with what is needed to score them
- **6. Risk-first placements** — items scheduled early against their score, each with the assumption they are there to test
- **7. Parked** — deferred items, each with the condition that would bring it forward
- **8. Trade-offs** — what was displaced, by what, agreed by whom, when
- **9. Re-cut triggers** — the facts whose change reorders this plan
- **10. Missing information** — what could not be scored or sequenced, and who can supply it

## Validation

The plan is ready when all of these hold:

- Every item in the input scope appears exactly once, in a release or under `Parked`
- Every release states whether it is independently useful
- Every external dependency names an owner outside the team
- Every `unscored` item says what is needed to score it
- Section 8 is non-empty whenever anything was deferred
- No value or effort figure appears that did not come from an input

Fail the run if an input item is missing from the output, or if a number appears with no source.

## Failure handling

- **No effort figures** — produce the plan with every item `unscored`, sequence on dependencies and risk alone, and state in section 10 that the order is provisional until the work is sized.
- **No agreed outcome** — stop. Report that prioritisation has no objective to optimise for; ordering without one is preference dressed as method.
- **Conflicting must-be-first demands** — place the items by dependency and risk, record each stakeholder's position in section 8 with their name against it, and raise the conflict as a decision someone must make. Do not average them.
- **A dependency with no owner** — list it as `owner unknown` in section 3 and as blocking in section 10. An unowned external dependency is the most common cause of a missed date.
- **Scope still open** — sequence what is agreed, list the rest as `pending scope`, and mark the whole plan `PROVISIONAL`.