> For the complete documentation index, see [llms.txt](https://framework.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.aic.io/agile-delivery-playbook/delivery-system/roadmaps-prioritisation-and-planning.md).

# Roadmaps, Prioritisation and Planning

### Overview

Planning is continuous in agile delivery. We plan enough to create direction, alignment and confidence, while keeping enough flexibility to respond to learning.

### Roadmap Purpose

A roadmap shows the direction of travel. It explains how outcomes will be approached over time.

A roadmap should help people understand:

* the vision
* the major phases
* the expected sequence of work
* the main releases or increments
* key dependencies
* major risks
* decision points
* intended value
* confidence level

### Roadmap Rules

A useful roadmap is:

* simple enough to understand
* visible to the right stakeholders
* reviewed regularly
* focused on outcomes rather than fixed feature promises
* honest about uncertainty
* connected to the backlog
* connected to governance decisions

### Planning Levels

We plan at five levels:

### 1. Outcome Planning

Defines why the work matters.

Typical questions:

* What outcome are we trying to create?
* Who benefits?
* How will success be measured?
* What risk are we reducing?

### 2. Phase Planning

Defines what must be achieved in discovery, alpha, beta, live or retirement.

Typical questions:

* What evidence is needed by the end of the phase?
* What decision will the phase support?
* What outputs are required?
* What are the entry and exit criteria?

### 3. Roadmap Planning

Defines the expected sequence of work.

Typical questions:

* What should happen first?
* What depends on what?
* Where are the decision points?
* Where should we build, test, release or stop?

### 4. Release Planning

Defines what will be released and when.

Typical questions:

* What is included in the release?
* What is excluded?
* What acceptance evidence is required?
* What operational readiness is needed?

### 5. Sprint or Flow Planning

Defines what the team is doing now.

Typical questions:

* What is the immediate objective?
* What can the team complete?
* What blockers exist?
* What does done mean?

### Prioritisation Criteria

We prioritise based on:

* user value
* customer value
* risk reduction
* legal or regulatory need
* security importance
* operational importance
* delivery dependency
* technical dependency
* effort
* urgency
* commercial impact
* learning value

### MoSCoW Prioritisation

MoSCoW can be used where helpful:

* Must have: essential to the phase or release
* Should have: important but not essential
* Could have: useful if capacity allows
* Won't have now: not included in the current timebox

MoSCoW should not be used as a substitute for hard trade-off decisions. If everything is marked must-have, prioritisation has failed.

### Prioritisation by Phase

Discovery priorities:

* understand the problem
* identify users
* identify constraints
* test whether further work is justified

Alpha priorities:

* test risky assumptions
* compare options
* learn quickly
* avoid premature production build

Beta priorities:

* build usable service increments
* validate with real users
* assure security and quality
* prepare for live

Live priorities:

* maintain service health
* improve performance
* respond to user evidence
* manage technical debt

Retirement priorities:

* protect users
* protect data
* manage transition
* decommission safely

### Planning Evidence

Planning artefacts should include:

* roadmap
* backlog
* release plan
* milestone plan
* sprint plan
* dependency log
* decision log
* RAID log