---
name: milestone-planning
description: Break a project into milestones that each prove something, so progress is verifiable rather than asserted. Use when a project is long enough that the end is not visible from the start.
---

# Milestone planning

A milestone is a checkpoint that demonstrates something works, not a
date by which effort has been expended. Milestones defined by activity
rather than outcome let a project be ninety percent complete for months.

## Method

1. **Define each milestone by a demonstrable outcome.** Something you
   can show or test, since design complete is unverifiable while a
   working end-to-end path is not.
2. **Front-load the risk.** The first milestone should prove the most
   uncertain assumption, because learning it fails early is the whole
   point (see project-risk-management).
3. **Keep milestones close together.** Two to four weeks apart, so a
   slipping project is visible within weeks rather than at the end.
4. **Build a thin end-to-end slice first.** A narrow path through the
   whole system finds integration problems that layer-by-layer
   construction defers to the end.
5. **Make each independently valuable where possible.** A project that
   delivers something at each milestone survives cancellation and
   reprioritisation.
6. **Do not move a milestone without a decision.** Slipping dates
   silently is how a plan detaches from reality (see
   scope-change-control).
7. **Review at each one honestly.** What was learned and whether the
   plan still holds, rather than only whether the date was met.

## Boundaries

Milestones structure delivery; they cannot create certainty about work
that is genuinely exploratory. Too many creates ceremony overhead.
Milestone dates are estimates and inherit their uncertainty (see
estimation-techniques).