When The Form Sets Your Batch Size

The batch-size argument in this library, and in the lean literature it comes from, contains an assumption so well hidden that it is almost never stated: that batch size is a decision. Lower the transaction cost of a release, the argument goes, and the economic optimum moves down, so release more often in smaller pieces.

That holds for software, where a change can in principle be arbitrarily small — one line, behind a flag, shipped to two per cent of users. It does not hold everywhere, and the places it fails are not edge cases. You cannot publish a quarter of an episode. You cannot file two thirds of a regulatory submission, print half a run, release forty per cent of an album, or close a month partially. A great many value streams have a minimum viable unit that the form imposes and no amount of engineering removes.

When the floor sits above where the economics would put you, "reduce batch size" is not advice. It is a description of something unavailable. What follows is what to do instead, and it turns out the underlying economics are not only intact but more useful, because they tell you exactly which lever is left.

Where the floor comes from

It is worth separating genuine floors from ones that are merely load-bearing habits, because most organisations have far more of the second than the first.

A real floor is imposed by the artefact or by an external party. A story episode has to resolve something or it is not an episode. A statutory filing is complete or it is rejected. A physical print run has a setup cost that makes anything under a threshold absurd. An app store submission is reviewed as a whole build.

A false floor is imposed by a process someone designed. "We release quarterly" is not a floor. "Legal reviews in batches because that is when the committee meets" is not a floor; it is a committee schedule. "We hold features until the marketing beat" is a coordination choice. These feel identical from inside and are worth attacking first, because the standard advice does apply to them and the gains are immediate.

The test is simple: ask what physically prevents shipping half of this. If the answer names a person, a meeting or a convention, the floor is false.

Why batch size has an optimum — and why it moves

• Transaction cost — falls as batches get bigger
• Holding cost — rises as batches get bigger
• Total cost

The move: separate the release batch from the work batch

Here is the thing that makes the whole problem tractable. The release being atomic says nothing about the work being atomic.

An episode ships whole. It does not have to be made whole. The outline can be reviewed on its own, the first act can be drafted and critiqued while the third is unwritten, continuity can be checked incrementally, the score can be scored against a locked cut. Every one of those is a small batch with its own feedback loop, sitting inside a release that happens to be indivisible.

This is precisely what trunk-based development does for software teams that release monthly. The release cadence is monthly; the integration cadence is hourly. The discipline that matters was never the release frequency — it was the feedback frequency, and people conflate them because in a well-run software team they happen to coincide.

So the question stops being "how do we ship smaller" and becomes "where is the largest gap between doing something and finding out whether it was right?" That gap is the actual pathology, and it can be closed without touching the release at all.

In a production pipeline the worst offender is almost always structural: premise, argument, or shape. It is decided first, discovered last, and costs the entire artefact when wrong. Closing that particular loop — a reading of the outline, a rough cut, a two-hundred-word sample of the voice — costs hours and saves weeks, and it is available no matter how indivisible the final thing is.

The second move: serialisation is batch-size reduction

There is a subtler point here that is easy to miss because it looks like an artistic decision rather than an operational one.

A novel has a large minimum unit. A serialised story does not. Chapters, episodes, issues and seasons are, in flow terms, the technique of lowering a floor that was assumed to be fixed — and they were invented for commercial and logistical reasons long before anyone drew a cumulative flow diagram. Dickens serialised for cash flow. The result was a feedback loop with readers that a completed manuscript cannot have.

The same restructuring is available in a lot of places it is not considered. A large research report becomes a series with a through-line. A campaign becomes a sequence that responds to what the first pieces did. A platform migration becomes a strangler pattern. In each case the form was treated as fixed, and it was not; the floor was a property of the chosen structure rather than of the work.

This is the one move that genuinely lowers the floor rather than working around it, and it is worth asking about before accepting any minimum unit as given. The cost is real: serialisation constrains what you can do later, which is the subject of a separate argument about published commitments. But the flow benefit is large and mostly unexamined.

The third move: pre-produce, release on cadence

When the floor is real and cannot be restructured away, decouple production from release entirely.

Work continuously, accumulate finished units, and release them on a rhythm. This is a release train, and it buys two things. Output becomes predictable to everyone downstream — marketing, distribution, the audience — which removes an entire category of coordination cost. And production variance stops propagating to the release date, because the buffer absorbs it.

It costs inventory, which is not free: finished work waiting to go out is capital tied up, and in fast-moving subject matter it decays. So size the buffer deliberately rather than letting it grow. Two or three units of slack is a schedule that survives someone being ill. Twelve is a warehouse, and a signal that you are producing faster than you can release, which is the subject of the verification argument.

What is left when batch size is fixed

Return to the economics. Optimal batch size balances transaction cost against holding cost. If batch size is pinned at the floor, you have two remaining levers and both are real.

Lower the transaction cost anyway. Even at a fixed batch, everything that makes a release expensive — the approval chain, the manual assembly, the platform submission, the rebuild of assets in four formats, the sign-off that waits for a person's return — is pure overhead paid every single time. Reducing it does not change the batch size, but it takes cost directly off every release, and it makes the next structural conversation possible. Most floors that turn out to be false were held in place by a transaction cost nobody had measured.

Lower the holding cost. Holding cost is mostly the cost of being wrong for longer: work done against assumptions that have not been tested. Cheap early feedback on the riskiest assumption reduces it without any change to the release at all. This is the same lever as the second section, stated in the vocabulary of the model.

What you cannot do is pretend the floor is not there. Teams told to reduce batch size when they cannot respond by faking it: shipping a nominal increment that no user can use, splitting a filing into parts that must all arrive together anyway, declaring a phase complete to hit a cadence. That is the worst outcome available, because it has the ceremony of small batches and none of the feedback, and it destroys confidence in the idea for everyone watching.

What to do on Monday

1. Write down your minimum release unit and the single sentence explaining what enforces it. If that sentence names a meeting, a team or a habit, you have a false floor and the standard advice applies — go and use it.
2. For one real release, list every step between "the work is done" and "it is live", with the time each took. That total is your transaction cost. Most teams have never seen it written down and it is larger than they expect.
3. Find the decision that is made earliest and validated latest. That is your worst feedback loop, and it is almost certainly structural rather than executional.
4. Build one cheap early check for it this week — an outline reading, a rough, a sample, a spike. Not a gate with a form. A conversation with the one person whose objection would have mattered.
5. Ask the serialisation question out loud, even if the answer is no: is the minimum unit a property of the work, or of the shape we chose for it?
6. If you already pre-produce, count the buffer. Decide what it should be and say why, rather than discovering the number by accident.