Shippable milestones

A milestone is not a date and not an internal checkpoint. It is a usable capability boundary — a place a real role can stop and use the product.

Group the rungs so each group ends at a point a real user can use. The Portal's web chapter F6 draws three milestones on its real phoenix.roadmap.md. Pick a rung on the right to see which milestone it completes — and the capability that boundary unlocks.

The three milestones Where a cut is shippable On the Portal References

Group a rung into its milestone · pick one

f6.1 → milestone 1 · Ship the catalog (f6.1–f6.5.5) · boundary: browse a persistent catalog and add courses. A milestone ends where a real role can stop and use the product.

A milestone is a usable capability boundary

A2 produced a value ladder of stories — a backlog. A backlog left alone ships in the wrong order, or all at once. The first move of the roadmap layer is to group the rungs into milestones, where a milestone is a usable capability boundary: a contiguous group of rungs whose completion leaves a real role able to do something useful. The test is plain — could you stop there and still have a product worth using?

F6 groups its nine rungs into three milestones, verbatim from phoenix.roadmap.md:

1 · catalog: Ship the catalog (f6.1–f6.5.5), verbatim: “browse a persistent catalog and add courses, server-rendered in the jonnify design system, with inline errors”. The first deployable product.
2 · live: Make it live (f6.6–f6.7), verbatim: “search and create without reloads; every client updates live with a viewer count”.
3 · users: Ship to users (f6.8–f6.9), verbatim: “sign in, run behind auth on a deployed clustered release, watch an operations dashboard”.

Each milestone is a place a real role can stop. Re-grouping the rungs changes where those boundaries fall — that edits the roadmap, never a spec.

Where a cut is shippable

Not every stopping point is a milestone. A cut is a usable capability boundary only if a real role could use the product there. Cutting after f6.4 — the domain over the facade — leaves no rendered page: a developer can read and write the domain, but no learner can browse. So f6.4 is not a boundary; f6.5.5, the rendered persistent catalog, is.

The boundary test below checks three candidate cuts against that rule. It teaches a different move from the hero: the hero groups a rung into one of the shipped milestones; this asks whether an arbitrary cut would ship.

Is this cut a shippable milestone? · pick one

cut after f6.4 → not yet usable: the domain is wired over the facade, but no page is rendered, so no learner can browse. Not a milestone boundary.

Draw the milestone where a user could stop and still have something worth using — not at the convenient stopping point.

Shippable milestones, on the Portal

On the Portal — the learning platform this course builds — the web chapter F6 draws its three milestones at the three capability boundaries. Ship the catalog ends at f6.5.5, the first deployable product: a learner browses a persistent catalog and adds courses. Make it live layers interactivity. Ship to users adds auth, deployment, and a dashboard.

The grouping is a property of the roadmap, not of any rung's behaviour. Moving f6.6 into milestone one, or splitting milestone three, edits phoenix.roadmap.md and leaves every f6.N.md spec exactly as written.

# phoenix.roadmap.md — the delivery arc (verbatim cells; grouping only).
#   | Milestone            | Rungs       | What you can do at the end          |
#   | 1 · Ship the catalog | f6.1–f6.5.5 | browse a persistent catalog, add    |
#   | 2 · Make it live     | f6.6–f6.7   | search and create without reloads   |
#   | 3 · Ship to users    | f6.8–f6.9   | sign in, deploy, watch a dashboard  |

# A milestone is a usable capability boundary: a real role can stop and use it.
boundary = "after f6.5.5 — browse a persistent catalog"  # usable
boundary = "after f6.4 — domain wired, no page rendered"   # not yet usable

# Re-grouping rungs edits the roadmap; every f6.N.md spec is untouched.

the principle

A milestone is a usable capability boundary — a contiguous group of rungs that leaves a real role able to do something useful, not an internal checkpoint.

on the Portal

F6 draws three: catalog, live, users. Each boundary is a deployable product over the one Portal facade; re-grouping rungs edits the roadmap, never a spec.

Draw the milestone at the capability, not at the convenient stopping point.

Recap — group at the capability

A milestone is a usable capability boundary. F6 draws three — ship the catalog, make it live, ship to users — each ending where a real role can stop and use the product. A cut that leaves no usable capability, like after f6.4, is not a milestone. Re-grouping rungs edits the roadmap, never a spec. With the milestones drawn, the next dive sizes each rung inside them: one iteration over Ships, Demo, Harness, Feedback.

Next in A3.5: A3.5.2 · The iteration loop — one iteration per rung, and the per-rung loop sharpen → build → ship → demo → review → feedback → adapt.

References

The delivery-planning sources behind shippable milestones, and where it connects in the course.

Sources

Humble & Farley — Continuous Delivery — deployable increments and releasing at a usable capability boundary.
Beck, K. — Extreme Programming Explained — small releases that each deliver business value.
Hunt & Thomas — The Pragmatic Programmer — good-enough software and shipping in usable slices.

Related in this course

A3.5 · Milestones and iterations — the module hub.
A3.5.2 · The iteration loop — the next dive.
A3.3.2 · The iteration table — the table read row by row.
A3.2 · XP for small batches — why small releases lower risk.
A3 · The roadmap layer — the chapter this sits in.
F6 · The Portal on the web (Phoenix) — the real chapter this roadmap plans.