Small Batches

Working in small batches means delivering changes in useful increments so feedback can arrive before more work accumulates. DORA recommends the practice where teams need to test an assumption quickly and revise their direction when the result disagrees.

A note on the word first, because it is badly overloaded. “Batch” here means the size of a change being delivered. It is unrelated to batch data processing, where a batch is a bounded set of records. A team can process data nightly and still deliver code in small batches; the two decisions have nothing to do with each other.

Why batches get large

DORA identifies fixed handoff cost as one reason work accumulates into large batches. This makes the delivery process itself a candidate for improvement rather than attributing batch size only to team habits.

If each release requires two days of coordination, combining changes spreads that fixed effort across more work. But it also postpones feedback and can make diagnosis and recovery harder. Compare those costs before calling a large batch economical.

Continuous delivery seeks to make small batches viable by lowering repeated delivery costs. Automation and a simpler handoff can remove overhead, while decomposition, testing, and integration still require skill and discipline. Changing incentives supports the practice; it does not perform the work for the team.

How small, concretely

The recommended test for a unit of work is the INVEST set, which is more demanding than it first looks.

• Independent — aim to develop, deploy, and validate a batch without waiting for another batch. Changes that must reach production together still form a coupled release batch.
• Negotiable — revise the work as feedback changes what is needed.
• Valuable — usable, and providing value to stakeholders.
• Estimable — enough is known to size the scope.
• Small — DORA recommends increments of hours to a couple of days.
• Testable — define how tests, monitoring, and observation will establish the expected behavior.

DORA treats a code batch taking more than a week to complete and check as too large and recommends features that take only a few days to develop. The purpose is timely validation; include checking time when discussing size.

A batch is sized by the work needed to implement and validate it, not by coding time alone.

Integrate changes before the whole feature is complete

DORA recommends integrating small releasable changes into trunk at least daily, including changes toward a feature that is not yet complete. A larger feature and one safe increment toward it need not have the same completion boundary.

A completed slice that is independently useful can be exposed to users. Paths that do not yet meet their contract need isolation: dark launching separates deployment from exposure, feature toggles select behavior, and branch by abstraction supports incremental structural changes. These controls do not establish safety by themselves. Test the intended production and fallback configurations, including shared dependencies and initialization; a hidden UI does not prevent all effects from deployed code.

These techniques provide ways to keep integrating without retaining all work on long-lived feature branches. The right approach depends on how the work can be divided and kept compatible. Git branch and merge explains the histories that later need combining. DORA treats small batches as a prerequisite for continuous integration and trunk-based development, rather than something a branch name alone achieves.

When a batch is done

In DORA’s approach, a work batch reaches completion after deployment and the start of feedback that validates it. That feedback can include user observation, monitoring, QA, and automated checks.

Under that definition, work that is merged but undeployed is inventory rather than progress — which is uncomfortable and correct, because an unshipped change has consumed cost and has not yet returned the one kind of information that only production supplies: whether it does what users needed, under real load, alongside everything else running there. It is not information-free. Compilation, unit and integration tests, review and prototypes all answer real questions about design and correctness, and they are cheaper answers precisely because they arrive before deployment. The point of the stricter definition is that those answers cannot close the loop on value, so counting the work as finished when they pass is what lets inventory build up unnoticed. Making this definition affordable is the real argument for test automation: not proving correctness in the abstract, but making it cheap to find out, which is where unit and integration tests pay for themselves.

What it costs, and one current reason it matters more

Decomposing work into independently useful and deployable pieces takes practice. Temporary toggles also add maintenance and testing work. Compare that cost with the delay, coordination, and recovery risk of larger releases, and remove obsolete toggles as features settle. DORA explicitly notes that decomposition requires experience.

DORA’s small-batch guidance also addresses AI-assisted development: faster code generation can produce changes that remain difficult to review, test, and integrate. Small verified increments are a proposed countermeasure to that risk; generating code faster does not establish that it is easier to validate.

Where the recommendation to shrink batches usually comes from is a look at the whole flow, which is value stream mapping; where the result shows up is the DORA metrics, in both throughput and stability. How the three fit together is worked through in Six Weeks of Waiting, Two Days of Work.

References

• DORA — Working in small batches (December 8, 2025)
• Pete Hodgson — Feature Toggles