A3.2 · Small batches · dive 1
Small releases
The first Extreme Programming practice: release small, release often. A small release is one whose batch is as close to a single increment as the work allows.
A smaller batch lowers the cost of a mistake, shortens feedback latency, and raises learning per cycle. Slide the batch on the right across the Portal’s nine-rung F6 ladder; the releases re-group and the readout reports how often a review fires and how much is at risk in one release.
Split the F6 ladder into releases · slide the batch
A small release is a batch of one — the most frequent review and the least at stake if a release turns out wrong.
What a small release is
A release ships a batch — the work done between two reviews. A small release shrinks that batch toward a single increment: one rung, cheap to ship, cheap to review, cheap to undo. Extreme Programming names this as its own practice because the size of the batch sets the cost of being wrong. Ship nine rungs in one release and a flaw in rung two is discovered with seven more built on top of it; ship one rung at a time and the same flaw is caught with nothing built on it yet.
Three quantities follow the batch size, and the hero figure moves all three. Feedback latency — how long until the work meets a reviewer — is the batch size in rungs: a review fires once per release. Blast radius — how much a single bad release puts at risk — is one batch. And the number of releases, hence the number of reviews for the same total work, falls as the batch grows. Release small, release often.
- batch
- The work shipped between two reviews — the unit a small release shrinks.
- small release
- A release whose batch is one increment (one rung): cheap to ship, review, and undo.
- feedback latency
- How long, in rungs of work, until a slice meets a reviewer. A review fires once per release, so latency equals the batch size.
- blast radius
- How much one bad release puts at risk — one batch. Smaller batch, smaller blast radius.
The cost of a small release is the cost of cutting and reviewing more often; the next section weighs that against what a small release buys — risk down, learning up.
Risk versus learning
Risk and learning move in opposite directions as the batch changes, and that is the whole case for a small release. A larger batch puts more at risk in one release (risk up) but passes the same work through fewer reviews (learning down). A smaller batch reverses both: less at risk per release, and more reviews for the same total work. Select a batch size below to render the two as a trade-off over the fixed nine-rung model.
Risk and learning per cycle · pick a batch size
Risk and learning trade off across the batch — shrink it and you give up nothing but the cost of reviewing more often.
Small releases on the Portal
The Portal’s web chapter is the worked case. Its phoenix.roadmap.md climbs
nine rungs f6.1…f6.9, and it does not ship them in one release. F6.1 ships
the engine served as a web app, it is demoed (“hit the root, see a page”), feedback is taken,
and only then is F6.2 planned. Each rung is defined as a PR-sized increment — a spec triad, the slice,
a green harness, a demo, and a feedback note. That is a batch of one, by construction.
What makes a batch of one the default here, rather than an aspiration, is the Author. A Claude agent turns one rung into its triad and its green harness, so producing a single small release is cheap. The batch stays at one not because a team holds the line against shipping everything at once, but because one rung is the natural unit of work the agent ships.
# phoenix.roadmap.md — nine rungs, each a small release (a batch of one). # F6.1 the engine served as a web app → demo: hit the root, see a page # F6.2 the route surface → demo: navigate routes # ... # F6.9 an operations dashboard → demo: the dashboard updates live # Per rung: a spec triad, the slice, a green harness, a demo, a feedback note. # Ship F6.1 → demo → feedback → THEN plan F6.2. The batch never grows past one rung. id = Portal.ID.generate(:course) # the slice ships behind the unchanged Portal facade
The principle
Release small, release often: ship the smallest increment worth reviewing, so each release is cheap to ship, cheap to review, and cheap to undo, and feedback arrives sooner.
On the Portal
F6 ships one rung, demos it, and takes feedback before the next is planned — nine small releases,
each a PR-sized batch of one the Author makes cheap to produce.
A small release is a batch of one; the F6 ladder is nine of them, each shipped and reviewed before the next is planned.
Recap — the batch of one
A small release shrinks the batch — the work between two reviews — toward a single increment. That lowers feedback latency (a review per release), shrinks the blast radius (one batch at risk), and raises learning per cycle (more reviews for the same work). On the Portal, the nine-rung F6 ladder is nine small releases, and a Claude agent makes each batch of one cheap to produce. The next dive holds the batch small from a different angle: not how often it ships, but how its design grows.
Next in A3.2: A3.2.2 · Incremental design — the design grown one rung at a time behind a stable facade, never drawn up front.
References
Primary sources for small releases and small batches, and where this dive connects in the course and to the real F6 chapter.
Sources
- Beck, K. — Extreme Programming Explained — small releases as a named practice: release small, release often.
- Humble, J. & Farley, D. — Continuous Delivery — small batches and the economics of shipping the smallest releasable increment.
- Hunt, A. & Thomas, D. — The Pragmatic Programmer — incremental delivery and the cost of a long feedback loop.
Related in this course
- A3.2 · Small batches — the module hub.
- A3.2.2 · Incremental design — the next dive.
- A1.01 · The two failure modes — big-bang versus the thin slice a small release ships.
- A1.03 · The Author/Operator loop — the cadence that runs one rung end to end.
- Companion · Phoenix (F6) — the real nine-rung ladder, shipped one small release at a time.