Disciplined Agile

Simplicity Factor: Batch Size

Back to Dealing with Complexity by Creating a Bias For Simplicity

Why look at this

Often reducing batch size is all it takes to bring a system back into control – Dr. Eli Goldratt

One of the mantras of Flow and Lean is to work on small batches. Attending to batch size is important for several reasons. The most common one is that small batches can be done quickly, are easier to manage and can be delivered to customers quickly. But small batches also force product managers to focus on what’s most important. This is essential when trying to sequence work. When there are conflicts as to how to allocate capacity to different work items, using large work items complicates this because not all of one work item is more important than all of another work item.  When a new product is being created MVPs are quite useful and start us with small pieces. But we often have large initiatives that relate to existing products or services. In this case we have to break these initiatives into smaller pieces – Minimum Business Increments.

it is important to understand that batch size occurs at different levels. We have both the specific size of the items being worked on as well as the total amount of work in process. For example, in a Scrum team, the size of the story is the batch size being worked on the the Sprint backlog is the batch of work to be accomplished. Both “being worked on” batch size and “work in process” batch size are important to attend to.

When batch sizes are too large:

  • it causes people to be less effective
  • it causes delays in the workflow and in getting feedback which creates waste
  • it delays the realization of value
  • it makes it difficult to collaborate

Desired batch size by level:

  • being worked on by an individual (e.g., story) – less than three days
  • work in process for a team (e.g., team backlog) – less than 2 weeks
  • work in process for an organization – 1-3 months, the smaller the better


Symptoms that your batches are too large

  • People working on too many projects
  • Work taking much longer than it should
  • Projects being worked on by many people part time


What causes this

Common causes are:

  • not using minimum Business Increments
  • not developing in small increments
  • not managing dependencies between teams making it difficult to decompose what needs to be built


What we want to achieve

Working on small batches at the different parts of the value stream. At the intake part of the value stream we should be using MVPs and MBIs. At the program level, we should be having small components that can be built and validated. At the team level we should have as little work in process as possible while keeping people productive.


Common solutions

  • use MBIs to have smaller batches coming in
  • decouple teams so the total work in process can be lowered
  • have cross-functional and dedicated product teams so fewer items so batches coming in can be completed quickly
  • An essential one is using MBIs.
  • Create visibility on all work in the system
  • Right-size the work waiting to be started using MVPs, MBIs, and MVRs appropriately
  • Sequence work to be pulled
  • Create a focus on finishing (see Manage Work-in-Process (WIP) by Focusing on Finishing  for more)


Other simplicity factors that are directly related to this one