Reducing batch size

Shrinking batches shortens cycle time.

An item in a batch waits for every other item in that batch to be processed before it moves on, so time in queue grows roughly in proportion to batch size. Halve the batch of features per release and the average feature reaches users about twice as fast — without adding a single engineer.

Smaller batches make flow smoother and less variable.

Large batches arrive as lumps that swamp a downstream process and then leave it idle. Many small transfers turn a spiky arrival pattern into a nearly steady stream, which lowers queues at every following stage — e.g. a QA team receiving 3 stories a day instead of 30 every other week.

Smaller batches deliver feedback sooner.

You cannot learn whether work is right until the batch reaches the next step. A pull request of 50 lines is reviewed in an hour; a 5,000-line branch waits days, and every line written meanwhile is built on unverified assumptions.

Smaller batches lower risk.

Risk falls because cycle time is shorter (less exposure to change), feedback is faster (errors are caught before they propagate), and a failure affects fewer items. A failed deploy of one change is a quick rollback; a failed quarterly release is a crisis.

Smaller batches cut overhead.

It feels like big batches save overhead, but the overhead of large queues dominates: more status meetings, more re-prioritization, more tracking of stale items, more merge conflicts. Teams that move to small batches routinely find their coordination load goes down, not up.

Large batches lower efficiency.

Slow feedback means more work is done on top of a mistake before the mistake is found, so rework grows faster than batch size. Engineers also lose context: fixing a bug found the same day is quick; fixing one found three months later means re-learning the code first.

Large batches drain motivation and urgency.

When the deadline is a year away, a day's slip feels irrelevant and nobody sees the result of their work. Small batches give each person fast, visible results and a near deadline, so effort and ownership rise.

Large batches make cost and schedule grow exponentially.

Long projects have more time for requirements and technology to change, and every change triggers more rework and more delay, which invites more change. That is why a 6-month project slips a few weeks while a 3-year program slips by years.

Large batches tend to grow even larger.

A big, slow project is the only train leaving the station, so every stakeholder piles on scope; the extra scope delays it further, which attracts still more scope. Big projects also become too important to cancel, absorbing the best people and starving small ones.

A whole batch moves only as fast as its worst element.

If a release bundles 40 changes, the release ships when the slowest or riskiest change is ready — and the most sensitive change sets the review and testing rigor for all of them. The bigger the batch, the more likely it contains a slow or risky outlier.

The economic batch size is a U-curve trade-off between transaction cost and holding cost.

Each batch carries a fixed transaction cost (a release, a test campaign, a review meeting), which favors big batches; every item waiting in a batch carries holding cost (mostly cost of delay), which favors small ones. Their sum is a U-shaped curve with a flat bottom, so batch size is a continuous variable you can tune, and being somewhat off the optimum costs little.

Driving down transaction cost per batch lowers total cost and moves the optimum toward smaller batches.

The U-curve is not fixed: invest in test automation, one-click deploys or standing review slots, and the transaction cost falls, so the optimal batch shrinks and total cost drops. This is how continuous delivery became economical — not by ignoring transaction costs, but by eliminating them.

Reducing batch size saves much more than the simple U-curve predicts.

The classic U-curve counts only transaction and holding cost; it ignores slower feedback, extra rework, higher risk, overhead and lost motivation, all of which grow with batch size. Add them and the true optimum lies further left — and the first moves down from a huge batch pay off enormously.

Small batches let you fill capacity more precisely.

Packing a sprint or a test rig with a few big chunks leaves large unusable gaps — a 5-day item can't fit in 3 free days. Small work packages fill the gaps, so you can run at a chosen utilization instead of being forced over or under it.

Loose coupling between subsystems enables small batches.

If modules depend tightly on each other, changing one forces a coordinated big-bang change to many. Stable interfaces, modular architecture and backward-compatible APIs let each team ship small changes independently and in any order.

The transport batch matters more than the production batch.

A production batch (a setup-heavy operation) may need to stay large, but the transport batch — how much work is handed to the next step at once — can usually be cut to one item. Write the spec as one document if you like, but release it to developers section by section as each is done.

Proximity makes small batches possible.

When people sit together, the transaction cost of a conversation is nearly zero, so they exchange questions one at a time instead of batching them into a weekly meeting or a long email. Co-location (or always-on chat with overlapping hours) shrinks the batch size of communication.

Shorter run lengths reduce queues.

Alternating frequently between work types — short runs of each — keeps every type's queue small. A team that spends a whole quarter on features then a quarter on tech debt builds a large backlog of each; interleaving them every week keeps both flowing.

Good infrastructure enables small batches.

Small batches only pay when each transaction is cheap, and infrastructure is what makes it cheap: CI pipelines, automated test suites, feature flags, staging environments, and test fixtures that let a subsystem be verified without the whole product.

Sequence first the work that adds the most value for the least cost.

Within a batch, order matters: run the cheap tests most likely to fail first, and attack the riskiest unknowns early, so the batch reveals bad news at the lowest cost. A five-second lint step should never wait behind a forty-minute integration suite.

Cut batch size before you attack bottlenecks.

Adding capacity at a bottleneck is expensive and slow; reducing batch size is usually cheap and reduces queues everywhere, including at the bottleneck, by smoothing the flow into it. Shrink batches first, then see which bottlenecks still matter.

Change batch size as the economics change.

The optimum depends on transaction and holding costs, and both move during a project. As launch nears and cost of delay rises, the holding cost per waiting item goes up, so the right batch size shrinks — e.g. daily test cycles near release instead of weekly ones early on.