Small Batches

Working in small batches means delivering changes in the smallest useful increments rather than accumulating them into large releases. Published guidance frames it as a principle rather than a technique: “working in small batches is an essential principle in any discipline where feedback loops are important, or you want to learn quickly from your decisions.” It lets you test a hypothesis quickly and, if it is wrong, “course correct or revisit assumptions.”

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

The usual explanation is cultural — teams are not disciplined, or not doing agile properly. The published explanation is economic, and it is more useful: “one reason work is done in large batches is because of the large fixed cost of handing off changes.”

Read that as an incentive rather than a complaint. If shipping anything costs two days of coordination — a change board, a release window, manual regression testing, a deployment runbook someone has to walk through — then batching a quarter’s work into one release is the rational move. The fixed cost is being amortized. Teams doing this are responding correctly to the economics they were handed.

Which tells you where the fix is, and it is not exhortation. The stated purpose of continuous delivery is exactly this: “a goal of continuous delivery is to change the economics of the software delivery process, making it viable to work in small batches.” Lower the cost of a handoff and small batches stop needing discipline, because they become the cheaper option. Ask for small batches while a release still costs two days and you are asking people to volunteer for more overhead.

How small, concretely

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

• Independent — “so that teams can work on them in any order, and deploy and validate them independent of other batches of work.” This is the hard one, and the one that quietly fails: three batches that must ship together are one batch.
• Negotiable — “iterable and can be renegotiated as feedback is received.”
• Valuable — usable, and providing value to stakeholders.
• Estimable — enough is known to size the scope.
• Small — completable “in small increments of time, meaning hours to a couple days.”
• Testable — “tested, monitored, and verified as working in the way users expect.”

And a threshold you can actually apply in a planning conversation: “any batch of code that takes longer than a week to complete and check is too big.” The related pitfall names the most common failure directly — “not breaking up work into small enough pieces” — with the recommendation that “individual features take no more than a few days to develop.”

Note the phrase “and check.” A batch is not sized by how long it takes to write.

The conflict nobody warns you about

The practice comes with a specific recommendation about integration: “ideally, your developers should be checking multiple small releasable changes into trunk at least once per day.” And separately, guidance to “commit code independent of the status of the feature.”

Put those next to “don’t ship a half-finished feature to users” and they are in direct conflict — unless the unfinished part is unreachable. That is what dark launching is for: it “allows developers to check in code for small batches that have been completed, but for features that are not yet fully complete,” typically by starting at the API or service layer rather than the UI. A feature toggle — “a conditional statement based on configuration settings” — does the same job at the boundary of behaviour, and branch by abstraction does it for larger structural changes.

Without one of those mechanisms, teams resolve the conflict the only way left: long-lived feature branches. Which reintroduces the cost the practice was meant to remove, since a branch that lives for three weeks has to be merged against three weeks of other people’s changes — see Git branch and merge. This is also why small batches are described as “a necessary condition for both continuous integration and trunk-based development” rather than a consequence of them.

When a batch is done

The definition of done here is stricter than most teams use, and it is the part that makes the rest coherent: “batches of work aren’t complete until they’re deployed to production and the feedback process has begun to validate the changes.” Feedback can come from users, system monitoring, QA, or automated tests.

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

Small batches are not free, and pretending otherwise is why adoption stalls. Decomposing work so that pieces are independently valuable and independently deployable is a design skill that takes practice, and the guidance acknowledges this — the process “can be difficult and requires experience to develop.” Toggles accumulate, and a codebase full of stale ones is its own problem. The honest framing is that you are trading a batching cost for a decomposition cost, and the trade is usually worth it because the second one compounds into a capability while the first just recurs.

One reason the practice has become more load-bearing recently is worth quoting rather than paraphrasing, since it cuts against a common assumption about AI-assisted development: “AI adoption often leads to increased software delivery instability; working in small batches acts as a critical countermeasure to this risk, ensuring that the increased velocity from AI translates into value rather than chaos.” The mechanism is unsurprising once stated — “while AI excels at generating large blocks of code quickly, large changes are difficult to review, test, and integrate safely.” Faster generation does not make a large change easier to verify.

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.

Reference: DORA, Working in small batches (documentation dated 2025-12-08, checked September 2026).