Library→First Way: Flow→Concepts→Work in Small Batches
Work in Small Batches
Why smaller releases are safer, faster, and easier to debug than large ones — and how to break large work into deployable increments.
Video Lesson
A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.
The batch size problem
A batch is the amount of work that moves through the system together before being handed off or delivered. In software, a batch is often a release: all the features, bug fixes, and changes that ship together in one deployment.
Large batches feel efficient. Surely it is cheaper to deploy 50 changes at once than to deploy them one by one? The intuition is wrong. Large batches have large transaction costs: long review cycles, complex merge conflicts, hard-to-debug failures, and delayed feedback on whether each change works.
LARGE BATCH — monthly release
SMALL BATCH — daily releases
Why small batches are safer
Easier to debug
When a 3-change release breaks, the root cause is obvious. When a 50-change release breaks, debugging takes hours or days.
Faster feedback
A small change deployed today gets real user feedback today. A large batch delayed for 3 weeks means feedback is 3 weeks late.
Lower risk per change
Each small change is self-contained. Its scope is narrow. A rollback is simple and targeted, not a wholesale reversion.
Less merge conflict
Small, frequent merges to main avoid the diverging branches that create painful, error-prone merge conflicts in large batches.
DORA research consistently finds that elite teams deploy more frequently AND have lower change failure rates. Smaller batches are not just faster — they are measurably more reliable.
The economics of batch size
There are two costs involved in batch size decisions. Donald Reinertsen formalized this in The Principles of Product Development Flow:
Transaction cost
The fixed overhead of each release: coordination, review, deployment ceremony. Favors large batches (amortize the overhead).
Solution: automate and eliminate transaction costs
Holding cost
The cost of delay: features not yet delivered, feedback not yet received, bugs not yet caught. Favors small batches (reduce time in flight).
Solution: reduce batch size to minimize holding cost
The insight: transaction costs are not fixed. Continuous integration, automated testing, and deployment pipelines make transaction costs approach zero. When the cost of each deployment is near zero, the optimal batch size is one.
How to work in smaller batches
Breaking large work into small deployable units is a skill. These techniques help:
- 1
Feature flags
Deploy code that is not yet active. The feature is hidden behind a flag until it is ready to release. Decouples deploy from release.
- 2
Vertical slices
Instead of building the full data layer, then the full API, then the full UI — build one end-to-end slice of a feature at a time.
- 3
Branch by abstraction
Introduce an abstraction layer, build the new implementation behind it, then switch over. No long-running feature branches.
- 4
Strangler fig pattern
Replace an old system incrementally by routing traffic to a new system one endpoint at a time. Never a big-bang rewrite.
- 5
Short-lived branches
No branch lives longer than a day or two. Merge frequently to main. Use trunk-based development to keep changes small.
Small batches at Nexus Corp
Before M-04, Nexus Corp deployed once a month. Every release bundled 3-4 weeks of changes. A deployment failure required a full rollback of all changes, making it impossible to isolate the cause. The deployment window was treated as a high-risk event requiring weekend coverage.
After M-04, continuous deployment means each commit that passes the pipeline ships automatically. The "release event" no longer exists. Deployment is a non-event.
The goal is not to deploy once a day. The goal is to make deploying so safe and cheap that it can happen as many times as needed. Frequency is a consequence of safety, not a target in itself.
Further reading
Continuous Delivery — Humble & Farley
Chapter 1: The Problem of Delivering Software. The foundational case for small batches and deployment pipelines.
Lean Thinking — Womack & Jones
Chapter 3: Flow. The single-piece-flow concept from manufacturing — the origin of small batch thinking.
The Principles of Product Development Flow — Reinertsen
Chapter 5: Batch Size. The economics and mathematics of optimal batch size in product development.
DORA 2023 State of DevOps Report
Elite performers deploy on-demand, multiple times per day. The data on batch size and reliability.