A3.5 · The roadmap layer
Milestones and iterations
A backlog is not a delivery plan. The roadmap groups rungs into milestones — each a usable capability boundary — and runs each rung through one iteration.
The exemplar is the Portal's real web chapter — F6 (Phoenix) —
and its phoenix.roadmap.md: nine rungs f6.1…f6.9
grouped into three milestones (ship the catalog · make it live · ship to users), each rung an
iteration over Ships, Demo, Harness, Feedback. Assign a rung on the right to see which milestone it
completes.
Assign a rung to its milestone · pick one
Three milestones, one iteration each rung
A2 produced a backlog: a value ladder of stories. The roadmap layer turns it into a delivery plan in two
moves. First it groups the rungs into milestones — each a usable capability
boundary, a point where a real role can stop and use the product. F6 draws three, verbatim from
phoenix.roadmap.md: 1 · Ship the catalog (f6.1–f6.5.5),
2 · Make it live (f6.6–f6.7), 3 · Ship to users
(f6.8–f6.9).
Second, it runs each rung through one iteration over four columns — Ships, Demo, Harness, Feedback asked — each row a PR-sized increment. The third dive then sequences the ladder by dependency and product priority. Re-grouping rungs edits the roadmap, never a spec; the order is a property of the delivery plan, not of the behaviour each rung points at.
Group the rungs into milestones — each a usable capability boundary — and run each rung through one iteration over Ships, Demo, Harness, Feedback. The most valuable, least risky thread ships first.
F6's three milestones over the one Portal facade: ship the catalog · make
it live · ship to users. Re-grouping rungs edits the roadmap, never a spec.
A milestone is a place a real role can stop and use the product; the rungs in it are the iterations that get there.
The three dives
Each dive takes one move of the roadmap layer, in the arc shippable milestones → the iteration loop → sequencing the ladder: first what makes a milestone a usable boundary, then the single iteration each rung runs, then the order they climb in. Read them in order — A3.5.1 starts.
Shippable milestones
Grouping rungs so each group ends at a usable capability boundary — the three F6 milestones — with a boundary test for whether you could stop there and still ship.
The iteration loop
One iteration per rung over Ships, Demo, Harness, Feedback — the PR-sized increment — and the loop sharpen → build → ship → demo → review → feedback → adapt.
Sequencing the ladder
Ordering by dependency and product priority — the most valuable, least risky thread first — while the spec-edits counter stays at zero.
A3.5 builds on the anatomy module A3.3.2 · The iteration table, which read the table row by row; here the rungs are grouped into milestones and sequenced. Return to the A3 chapter navigation to continue.
References
The delivery-planning tradition behind milestones and iterations, and where it connects in the course.
Sources
- Humble & Farley — Continuous Delivery — releasing in thin, demoable increments grouped into deployable milestones.
- Beck, K. — Extreme Programming Explained — small releases and the planning game over an ordered backlog.
- Hunt & Thomas — The Pragmatic Programmer — the tracer bullet that leads the sequence, and good-enough increments.
Related in this course
- A3.5.1 · Shippable milestones
- A3.5.2 · The iteration loop
- A3.5.3 · Sequencing the ladder
- A3.3.2 · The iteration table — the table read row by row.
- A3.2 · XP for small batches — why a batch of one is the cheap default.
- A3 · The roadmap layer — the chapter this module sits in.
- F6 · The Portal on the web (Phoenix) — the real chapter this roadmap plans.
- Companion · Functional Programming in Elixir