Batch Size

The amount of work moved through a process in one increment. Small batches mean changes are made, integrated, and released in frequent tiny pieces rather than large infrequent ones. Reducing batch size is a core lean principle: it shortens cycle time, smooths flow, and surfaces problems sooner.

Why it Matters

Large batches accumulate risk and delay feedback: many changes ship together, so a failure is hard to isolate, and the gap between doing work and learning whether it worked grows. Small batches make each change low-risk and quick to verify, which is much of why high-performing delivery is both faster and more stable.

Signals

• Changes are integrated and released frequently in small pieces; a failure traces easily to the small change that caused it.
• Work in progress is limited rather than piling up.
• Anti-signal: big-bang releases bundling weeks of change, followed by long stabilization periods.

Benefits

Faster feedback, lower per-change risk, easier diagnosis, smoother flow, and reduced cost of delay.

Risks

Shrinking batch size without the supporting automation and testing just adds overhead per release. Some changes carry irreducible coordination and cannot be split arbitrarily.

Tensions

Smaller batches reduce risk and speed feedback but raise the per-release fixed cost, unless that cost is automated away. The lean answer is to drive down the transaction cost of releasing, not to batch work up so the cost is amortized over a big release.

Examples

Merging to trunk many times a day behind small, tested increments rather than integrating a long-lived branch once a month; releasing a feature incrementally behind a flag instead of all at once.