Software Batch Sizes are Plummeting

When I said Continuous Delivery is Inevitable I cited shorter iterations as the main driver. However, along with shorter iterations we’re also getting smaller batch sizes. And from a Lean perspective it is the smaller batch sizes that are more interesting.

Smaller is better when it comes to batch sizes, at least according to the guru of Lean Product Development Donald Reinertsen (2009). Smaller batch sizes leads to smaller changes, higher quality, shorter cycle time, more timely feedback, and ultimately greater profit. All very attractive.

Over the last 20 years the common batch sizes used in software development have plummeted. The diagram shows how the batch sizes have decreased more-or-less exponentially as the iteration length has shortened.

Smaller Batch Sizes

Smaller Batch Sizes

For my teams anyway the batch size is now a Gherkin Scenario rather than anything bigger. Developers work a Scenario at a time. When they are finished they merge it into trunk and this kicks of a automatic build and deployment process. Admittedly there is a lot of upstream work to refine large Epics into these discrete Scenarios (see Agile Requirements Snail) but the batch size for developers is less than a days work.

Of course I had to make some assumptions to be able to draw the diagram:

  • 10 developers
  • Velocity of 1 Scenario per developer per day
  • 20 days in a Scrum Sprint (working month)
  • 5 days in a XP Iteration
  • 5 Scenarios per User Story


Reinertsen, D. G. (2009). The principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.