Batch Size And The Cost Of Big Releases

If you could change one variable in a delivery organisation and were not allowed to change the people, the structure, the tooling or the process, you should change batch size. Nothing else touches as many outcomes at once. It moves cycle time, defect rate, diagnosis cost, forecast accuracy, feedback latency, merge pain and the political temperature of release weekend, and it moves all of them in the same direction.

It is also the variable that nobody owns. Ask who is accountable for velocity, quality or scope and you will get names. Ask who is accountable for how much change goes out in one go and you will get a shrug and a reference to the release calendar, which was set by a governance forum in a previous financial year for reasons nobody present can reconstruct.

This article is the economic argument for driving batch size down, the three separate mechanisms by which large batches hurt you, and the practical route when the release path itself is the thing making batches large.

The transaction cost trap

The reason organisations batch is entirely rational, and it is worth stating properly before dismantling it.

Every release carries a fixed cost that does not depend on how much is in it: regression testing, change advisory board paperwork, deployment runbooks, a communications plan, a warranty period, people on standby. Call this the transaction cost. If a release costs three days of effort regardless of size, then releasing weekly consumes an enormous fraction of your capacity, and releasing quarterly consumes almost none. Batching amortises the fixed cost.

Against that sits the holding cost: what it costs to keep finished work sitting unreleased. Delayed revenue, delayed learning, delayed defect discovery, and the accumulating risk that the change is now built on assumptions that have moved.

The classic result — this is the core of Reinertsen's treatment of batch size in product development flow — is that total cost is a U-shaped curve, and the optimum batch size sits where transaction cost and holding cost are roughly balanced. So far, so uncontroversial. Most organisations will happily agree with this and then use it to justify exactly the batch size they already have.

The two things they miss are what make the argument decisive.

The U is flat near the bottom and steep on the right. Getting batch size somewhat too small costs you very little. Getting it substantially too large costs you a great deal. Under uncertainty about where the optimum sits — and you are always uncertain — the rational error is to aim low.

Transaction cost is not a constant. It is a decision. This is the part that gets treated as physics when it is in fact policy. The three-day release process exists because somebody built it that way, and it can be rebuilt. Every reduction in transaction cost moves the optimum batch size to the left, which reduces holding cost, which frees capacity, which can be spent reducing transaction cost further. Organisations that understand this compound; organisations that treat their release cost as a fixed input negotiate forever over where to sit on a curve they could have moved.

Mechanism one: feedback delay

A batch of changes cannot teach you anything until it is released. Whatever you learn — that the feature is used differently than expected, that the performance characteristics are wrong, that a user flow confuses people — you learn once, at the end, about all of it at once.

The consequence is not just that learning is late. It is that learning is undifferentiated. When forty changes ship together and the conversion rate moves, you have one signal about forty decisions, and you cannot attribute it. The information content of the release is far lower than that of its parts released separately, and the loss is silent — nobody logs a ticket for the attribution you never had.

There is a second-order effect that is worse. When feedback is slow, teams stop treating it as an input and start treating it as a report. Work that was built on a hypothesis three months ago has, by the time the data arrives, already been followed by more work built on the same unvalidated hypothesis. Long feedback loops do not just delay correction; they multiply the amount of work that needs correcting. This is why continuous discovery is hard to run on top of a quarterly release cadence: the discovery cycle is faster than the delivery cycle, so the two decouple and discovery degrades into documentation.

Mechanism two: diagnosis cost scales worse than linearly

This is the mechanism that most convincingly wins arguments with engineering leadership, because engineers have all lived it.

Deploy one change. Something breaks. The candidate set of causes has one member. Diagnosis is minutes.

Deploy forty changes. Something breaks. The candidate set is not forty — it is forty, plus their interactions, plus the possibility that the failure is caused by two changes that are individually correct. You cannot bisect cleanly because the changes shipped together. You cannot roll back one because the deployment was atomic. You roll back everything, which punishes thirty-nine innocent changes and throws away weeks of queued value, or you fix forward under pressure at two in the morning with incomplete information.

The precise shape of the growth does not matter and I would not trust anyone who quoted you an exponent. What matters is that it is not linear: doubling the batch more than doubles the expected cost of diagnosing a failure in it. Larger batches are also more likely to contain a failure, so the expected cost of a release rises steeply on both terms at once.

This is the mechanism underneath one of the more counter-intuitive findings in the DORA research: organisations that deploy more frequently have lower change failure rates and recover faster. It reads as paradox until you see that frequency and size are inversely related, and that small changes are simply easier to verify, easier to reason about and easier to reverse. Speed and stability are not a trade-off. They are correlates, and batch size is the common cause. The metrics themselves are covered separately.

Mechanism three: variability accumulates

A large batch is a package of many items, and it is finished only when its slowest member is finished. If each item has some variability in completion — and in knowledge work each item has a great deal — then the batch inherits the worst tail of all of them.

Ten items each with a small chance of significant delay will produce a batch with a large chance of significant delay. This is why big releases slip and small ones do not, and why the slippage is always attributed to whichever item happened to be last rather than to the structural decision to couple them.

There is a coupling effect too. Items in a batch acquire dependencies on each other that they did not have when separate: shared branches, shared environments, shared sign-off. A batch does not merely contain risk; it manufactures it.

The quarterly release train as an antipattern

Some organisations respond to all of this by formalising the batch. A fixed release train, quarterly or on some similar cadence, with a cutoff date, a hardening period and a coordinated go-live. It feels like discipline. It produces predictability of date, which executives value, and it is defensible in a governance forum.

It is still an antipattern, for reasons that are structural rather than aesthetic.

Effect	What happens	Why it compounds
Cutoff scramble	Work rushes to make the train, quality falls at exactly the moment it matters most	The riskiest changes arrive with the least review time
Missed-train penalty	Missing by two days costs a full quarter	Creates strong incentive to force half-finished work in
Hardening period	A multi-week integration phase treated as normal	Defects found late, in bulk, with maximum diagnosis cost
Coupled scope	All changes succeed or fail together	One bad change can block an entire quarter of value
Estimation pressure	Long horizons demand long-range estimates	Drives estimation theatre and scope padding

The deeper problem is that a fixed train converts a continuous economic question — is this change worth releasing now? — into a scheduling question, and schedules are administered rather than optimised. Once the train exists, nobody re-asks whether it should. It appears in the governance pack as a fact about the organisation rather than a choice the organisation is making every quarter at considerable expense.

The honest version of the release train argument is that some organisations genuinely cannot deploy independently — because of hardware, regulatory certification, physical distribution, or a monolith with no seams. Those are real constraints and I would not pretend otherwise. But they are far rarer than the number of release trains in existence, and in most cases the train was inherited from a coupling that has since been engineered away without anybody updating the calendar.

Driving batch size down when the path is expensive

If your release path is cheap, you do not need advice; just release more often. The interesting case is when it is expensive and you cannot fix that this quarter. There is still a great deal available.

Separate deploy from release. This is the highest-leverage move available to most organisations and it is purely technical. Feature flags let code reach production continuously while the user-visible change is enabled separately. The deployment batch shrinks to near-continuous even though the release batch stays whatever the business wants. You get the diagnosis benefits and most of the integration benefits immediately, without asking anyone's permission to change the release calendar.

Shrink the integration batch first. Even where deployment is constrained, merge frequency usually is not. Long-lived branches are batches by another name, and they carry the same non-linear diagnosis cost at merge time. Moving to trunk-based development reduces batch size in the place where the pain is most acute and the permission required is least.

Split the work item, not just the release. Large stories produce large changes, regardless of release cadence. Right-sizing — splitting until items are roughly uniform and small enough to complete in a couple of days — reduces the granularity of everything downstream. Vertical slices that each deliver something demonstrable beat horizontal slices that must be assembled before anything works.

Automate the most-repeated manual step, once per quarter. Not a transformation programme. One step. The regression pack, or the environment provisioning, or the release note generation. Transaction cost falls in increments, and increments compound.

Make the holding cost visible. Nobody argues against batching because the cost is invisible. Put a number on it: value of work sitting finished-but-unreleased, and how long it has been sitting. A board column labelled "done, waiting for the train" with items ageing in it changes the conversation faster than any argument about queueing theory, because it converts an abstraction into inventory that people can see.

Decouple the approval from the deployment. Much release cost is governance rather than engineering. In many cases the same assurance can be provided by automated evidence generated continuously rather than a manual gate applied per release. This is available even in heavily regulated environments, where the requirement is almost always evidence of control, not a particular meeting.

What to do on Monday

Measure your current batch size honestly, in two ways. Count the number of distinct changes in your last three production releases. Then count the number of working days between the first commit in each release and the release date. The second number is your holding time, and it is usually the one that shocks people.

Take the single largest contributor to release cost and ask whether it is a policy or a physical constraint. Most are policies. Pick one policy and put a named owner and a date against removing it.

Then run one deliberately small release. Not a pilot programme, not a workstream — one release, containing a handful of changes, through the existing path, timed end to end. Compare the cost per change against your last normal release. That comparison is the entire argument, and it is much harder to dismiss than a curve on a slide.