‘Batches’ in Scrum

If you consider each of Scrum’s events, 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 on, and get feedback about, a batch of new work.

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

• Daily Scrum: The team is inspecting the batches of work they’ve done, the batch of things in flight, and the work remaining.

• 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 throughout the 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. Many teams operate with a similar understanding: each Sprint is a potential release. Things get interesting when a team is capable of releasing multiple times throughout the 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. Those ideas are transported as a batch to the next Sprint Planning event, each for consideration in the next Sprint or Sprints.

The Scrum Guide doesn’t use the word ‘batch’ - not even once. But the queuing of things and working/thinking in batches (of requirements, stories, releases, etc.) is necessary.

The four related quantities

It is easy to see why confusion arises around batch size. Four distinct quantities often get treated as if they are the exact same thing:

When people hear “reduce batch size”, the knee-jerk reaction is often to split PBIs into smaller pieces. But splitting stories 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 likely a good thing), but they’re still trying to move a large batch through the system.

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. If we are to believe Martin Fowler, who said, “Frequency Reduces Difficulty”, then establish a commitment with the team to release every hour. The pain caused by this activity will cause team members to pursue remedies to all related painpoints.

   • “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 3rd-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. If we are to believe Donald Reinertsen, who said, “try reducing your batch size by 33% to 50% and see what happens”, then 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.