‘Batches’ in Scrum

In 1995, when Scrum was introduced, the release of software was a monumental task involving the printing of floppy disks or CDs, user manuals, reference cards, and boxes. Producers directed immense capital toward packaging and distribution and hoped for prime visibility on retail shelves. Between releases, a conventional SDLC (i.e., “Waterfall”) appeared rational and teams would process a large batch of requirements toward the next release…many months away.

Scrum’s design, a Sprint is a month or less and the team must be capable of producing an increment of releasable functionality every Sprint, encouraged teams to process smaller batches of requirements and break down their annual “launch” into monthly (or less) release cycles. It is understandable how many Scrum teams understood their Sprint length to be equal to their release cadence.

But there’s nuance in Scrum’s design that evades many teams. This nuance was addressed in more recent revisions of the Scrum Guide: there was never a rule that the delivery of value, if a team was capable of doing so, be deferred until Sprint Review; rather, teams may release multiple times per day (e.g., CI/CD and related engineering practices have made this commonplace) and every Sprint is an opportunity to inspect those releases on a cadence that makes sense for the team and their stakeholders. Stakeholders may not need to inspect the product every time a developer releases a few lines of code mid-Sprint; but each Sprint Review ensures the team and their stakeholders assess whether recent increments are helping move things toward their Product Goal.

Hence, the new problem: as teams realize their releases can be decoupled from their Sprint cadence, they discover new ways their workflow contains queues and batches. It was always true that work batches (e.g., the items selected in Planning, the Done work stakeholders see at the Review, and the improvement ideas a Retrospective produces) but they are confronted with the likelihood their previous working agreements and policies are built around the wrong set of batches. If a Scrum team used to strive for one release per Sprint, their working agreements tolerate the queuing of Done work waiting for release. Some working agreements hold finished work, unstarted work, or improvements until a sibling is ready; doing so adds delay and risk but was tolerated because releasing once per Sprint was an improvement over their previous release cycle (quarterly or annual, et cetera).

Consider four related quantities

It is easy to see why confusion arises around batch size. For example, when people hear “reduce batch size”, the first reaction is to split Product Backlog Items (PBIs) into smaller pieces. I do encourage that, but splitting PBIs changes item size, not necessarily batch size. For example, if a team slices every PBI into a single day of work, but they start eight of them on Monday and release none until the Sprint Review, the batch size of their release remains eight. The items got smaller (which is a good thing), but they’re still trying to move a large batch through the system.

Understanding these four distinct quantities helps teams meaningfully scrutinize their workflow:

Consider where batches occur in your workflow

The Scrum Guide doesn’t use the word ‘batch’ - not even once. But the queuing of things and working/thinking in batches happens (sets of requirements, stories, releases, et cetera). And it matters which queues and batches a team cares about, measures, or eliminates.

If you consider each of Scrum’s events, for example, you’ll notice batches of various kinds:

• Sprint: The team conducts all their work in the context of Sprints and each Sprint is an opportunity to focus and get feedback on new work.

  • It’s likely the stakeholders perceive that new work as a batch.
  • Even if developers release smaller batches of work multiple times per Sprint, the stakeholders’ perception may be constrained to the Sprint cadence.

• Sprint Planning: The team is considering what portion of the Product Backlog to convert into functionality within the Sprint. They’ll negotiate a Sprint Goal and select PBIs from the top of the Product Backlog.

  • A team whose agreement is one batch of PBIs per Sprint will begin work on those PBIs all at once and strive to get them Done before Sprint Review.
  • A team that pulls items into progress when capacity allows and respects a WIP limit will deliver a PBI as soon as it’s Done.

• Daily Scrum: The team is inspecting their progress toward the Sprint Goal.

  • A team whose agreement is one batch of PBIs per Sprint is likely to find they have a lot of work in progress, moving in parallel, hopefully to converge before Sprint Review.
  • A Scrum team employing the Kanban strategy will impose limits on the number of PBIs in progress and their Daily Scrum is an opportunity to reflect on what has been released, what is next, and whether the flow of work is impeded in any way.

• Sprint Review: From the stakeholders’ perspective, all the Done work is available for inspection. This event is their formal opportunity to learn of the changes made to the product that Sprint. They are likely to think of those changes as a batch. They are accustomed to thinking of each Sprint as an investment, a feedback loop, a container of risk and opportunity.

  • A team whose agreement is one batch of PBIs per Sprint is likely to form working agreements around the idea that each Sprint is a potential release.
  • Employing the Kanban strategy helps teams establish working agreements that allow releasing multiple times per Sprint; they decouple their release cadence from their Sprint cadence and deliver small batches frequently into the hands of end users. This enables rapid feedback loops with real users, allowing the team to iterate on Product Backlog Items multiple times prior to the Sprint Review.

• Sprint Retrospective: Expected outcomes of a retro include actionable ideas for improvement. Each improvement idea may represent a batch of work for consideration in the next Sprint or Sprints.

  • A team whose agreement is one batch of PBIs per Sprint may be critical of having incomplete work at the Sprint Review. Their retrospective is likely to focus on ways to better forecast their capacity and prevent incomplete work. Their mindset requires that a batch of work is started and completed matching their Sprint cadence.
  • A Scrum team employing the Kanban strategy will reflect on their discipline regarding WIP limits and whether the cycle time per PBI exceeded their Sprint length. They’ll tolerate the fact that a number of PBIs were started in the days leading up to Sprint Review and not yet completed; they accept that as a consequence of flow rather than incrementalism.

The Benefits (and the Trade-offs)

Working and thinking in smaller batches produces positive outcomes:

Faster feedback: Releasing smaller batches of code lets end users see functionality sooner, giving you real-world feedback while the work is fresh.

Lower cognitive load: Managing a smaller batch of requirements keeps discussions focused and reduces context switching.

Easier troubleshooting: Reverting a small, isolated code change is easier than trying to untangle a massive release when something breaks.

Better momentum: Teams see the tangible outcome of their effort earlier, improving their sense of purpose.

Finding the right balance

However, there is a pitfall to watch out for: “smaller” is not automatically better in every circumstance.

Finding the optimal batch size requires finding the balance between two competing costs:

• Transaction cost: The effort required to move work (e.g., running tests, coordinating a release, holding alignment meetings).
• Holding cost: The risk and cost of keeping completed work waiting (e.g., merge conflicts, delayed feedback, hidden defects).

If your deployment process is manual and painful, then reducing your release batch size to every hour will create overwhelming overhead. In this scenario, there are two possible strategies to consider:

1. We might take Martin Fowler’s advice, who said, “Frequency Reduces Difficulty”. Establish a commitment with the team to release every hour and the pain caused by this activity will cause team members to pursue remedies to all related pain points.

   • “It takes too long to run the manual tests.” — They will write automated tests.
   • “We have merge conflicts in multiple branches.” — They will abandon their habits and discover TBD (Trunk-Based Development).
   • “The build takes too long.” — They will optimize the build process by caching assets and third-party modules.
   • …and so on.

   Choose Fowler’s approach when team culture is receptive to radical change and leadership supports short-term friction to achieve sophisticated automation.

2. Or we might take Donald Reinertsen’s advice, who said, “try reducing your batch size by 33% to 50% and see what happens”. You may avoid the disruption of #1 and gradually discover an optimal batch size for your current environment … then work on lowering your transaction costs (e.g., CI/CD, automated tests) so smaller batches become economical.

   Choose Reinertsen’s approach when the system is fragile, team capacity is constrained, or transaction costs are currently much too high for hourly releases.

Practical questions for your team

To reflect on batches in your current workflow, consider these questions during your next Sprint:

1. In Planning: Are we activating our entire Sprint Backlog at once or pulling items into progress only as capacity is available?
2. In Daily Scrum: Are items moving smoothly toward the Sprint Goal, or are things piling up waiting for review and testing?
3. In Review: Are stakeholders seeing features for the first time, or are we inspecting outcomes that users have already started using in production.
4. In Retro: Are we comfortable with the amount of incomplete work “carries over” to the next Sprint? Is it accidental or intentional? What steps can we take to minimize it?