Smaller Batches, Better Delivery? Find the Feedback Boundary

A roadmap commitment is slipping. The work has been in progress for weeks, yet nobody can say whether the difficult assumption holds. Testing waits for the complete feature. User acceptance waits for testing. Release waits for several related changes. The team is busy, but the decision remains starved of evidence.

The usual response is to split the work into smaller tickets. That may help, but it can also change nothing. Ten tickets can still travel as one batch if they must reunite before review, testing, release, or customer feedback. The board looks more granular while the business waits just as long.

This is why batch size deserves management attention. The useful question is not, “How many points should a story contain?” It is, “How much work must move together before we can learn something that matters?”

A useful software delivery batch is the smallest coherent slice that can reach meaningful feedback without waiting for the rest of the initiative. Smaller is not automatically better: the slice must still be testable, reviewable, releasable, or able to change a decision.

The batch is often somewhere else

Software work passes through several possible batch boundaries. Leaders approve groups of initiatives together. Teams start features together. Developers integrate code together. Reviewers, testers, business owners, and release managers may each wait for a different bundle.

A consequential delay can sit downstream from development. A team may merge code every day, then hold it for a fortnightly acceptance session. Another team may test individual changes but release only when a programme milestone is complete. A third may deploy frequently while waiting months to inspect whether users changed their behaviour.

Splitting work at the wrong boundary creates administration, not feedback. A useful slice has to cross the constraint that withholds evidence.

Middleton and Joyce (2012) studied a nine-person BBC Worldwide software team that changed how work moved through its system. The team limited work in progress, pulled new work when capacity became available, broke projects into smaller marketable features, improved automation, addressed technical debt, and removed blockers daily. Over the study period, delivery became substantially faster and more consistent. Release frequency rose, while customer-reported defect measures moved in the right direction.

That result matters, but its limits matter too. The study observed one stable team. Several practices changed together, and the team strengthened its engineering capability as the flow system matured. We cannot credit smaller batches alone. The case shows an association between the combined intervention and better aggregate outcomes; it does not show which change did the work.

Plausible explanations are more useful than a copied target, as long as they are read as interpretations rather than isolated findings. Lower work in progress may have reduced competing queues. Pull may have protected constrained roles from overload. Smaller coherent features may have reached feedback sooner. Automation may have made frequent delivery more practical. Visible blockers may have given the team a way to improve the system rather than merely accelerate coding. None of these pathways was separately established, so each is a hypothesis worth testing in your own system.

Smaller does not mean safer by default

Quality evidence makes the same point from another angle. Kamei et al. (2013) examined code changes across open-source and commercial systems. Change breadth and churn helped identify defect risk, but the useful predictors differed by context. A change touching more files can deserve more review attention, yet size is not a verdict. Small changes still introduced defects, and the prediction was far from perfect.

Khomh et al. (2015) found similarly mixed effects when Firefox moved to rapid releases. Bugs were fixed faster, but a smaller proportion was fixed, and the rapid-release versions crashed sooner at runtime. Shortening a release cycle improved some outcomes without improving all of them.

These studies examine different units: code changes, product releases, and deliverable features. They do not establish one ideal batch size. Together, they challenge two common shortcuts. Large batches can delay evidence and expand integration risk. Smaller batches can expose weak testing, overloaded review, poor release automation, or fragmented design.

The goal is not the smallest possible ticket. It is the earliest useful feedback at an acceptable cost of coordination and risk.

Find one feedback boundary on Monday

What follows is a practical synthesis drawn from these studies, not an intervention any of them tested directly. Treat it as a local experiment. Choose one commitment that is already slipping or feels unusually uncertain. Leave the rest of the portfolio alone for now.

First, name the earliest evidence that could change a real decision. Perhaps a technical test can reject an architectural assumption. A compliance review can expose a constraint. A thin user journey can show whether customers understand the interaction. An operational release can reveal whether support demand changes. Be specific about who will see the evidence and what decision it could alter.

Next, trace the queues before that point. Where does work wait for clarification, another team, review, a test environment, business acceptance, a release train, or access to users? Include queues outside the delivery team. The board may show active development while the decisive batch accumulates elsewhere.

Then design one coherent slice that can reach the evidence point independently. “Coherent” is doing important work here. A database task, service task, and interface task that must all finish before testing are three tickets but one delivery batch. Prefer a narrow end-to-end behaviour, a tested technical path, or a releasable option that can stand on its own.

Observe several slices before declaring victory. Track elapsed lead time and its variation, the age of active work, blocked time, and waiting before review, test, acceptance, and release. Add quality signals that fit the system: components touched, rework, rollback, escaped defects, or time to detection. Finally, record how long it took for the evidence to change a decision. Faster output without earlier learning is a weak result.

Use these signals to keep, adjust, or abandon the boundary. If review time grows, smaller development batches may have overloaded a constrained reviewer. If slices repeatedly reunite before release, the release policy is still setting the real batch. If every slice depends on the same unfinished platform change, the architecture is telling you something about coupling.

Manage the boundary, not the number

A universal story-point ceiling would be convenient. The studies selected here do not support one, and software systems differ too much for it to be credible. Team capability, architecture, automation, risk, and the type of feedback all change what “useful” means.

Leaders can still be precise. Ask where evidence is delayed. Make one boundary smaller without breaking coherence. Watch flow, quality, and learning together. Improve the enabling system when a new constraint appears.

Batch size then stops being a ticket-writing preference. It becomes a practical way to shorten the distance between a commitment and the evidence needed to steer it.

References

Kamei, Y., Shihab, E., Adams, B., Hassan, A. E., Mockus, A., Sinha, A., & Ubayashi, N. (2013). A large-scale empirical study of just-in-time quality assurance. IEEE Transactions on Software Engineering, 39(6), 757–773. https://doi.org/10.1109/TSE.2012.70

Khomh, F., Adams, B., Dhaliwal, T., & Zou, Y. (2015). Understanding the impact of rapid releases on software quality. Empirical Software Engineering, 20(2), 336–373. https://doi.org/10.1007/s10664-014-9308-x

Middleton, P., & Joyce, D. (2012). Lean software management: BBC Worldwide case study. IEEE Transactions on Engineering Management, 59(1), 20–32. https://doi.org/10.1109/TEM.2010.2081675

AI disclosure: AI was used to help create this article. Responsibility for the published content remains with Nico Thümler.