When Work in Process is piling up, big batches are a usual suspect. Batch size is the quantity of stuff contained in a unit of work, e.g. the number of features or the size of features contained in a story, or the number of stories in an EPIC.

Making batch size smaller consists in reducing the number of tasks that are bundled together, and that you need to finish together to consider your are done. That can be achieved through:

  • Separation of Concerns and decoupling. Identifying what are the problems you’re trying to fix, and isolating the solutions you’re bringing into different lots.
  • Target to iterate more by reducing the scope of your iterations. Plan smaller, but usually acceptable iterations, it helps creating smaller batches.
  • Identify priorities. Knowing what to do first can help cutting through batches.

The benefits of reducing batch size are applicable at every level of software engineering (be it planning or delivery), but also for a variety of aspects that may have nothing to do with software (organizing school expeditions, doing the laundry, writing a blog post or fixing your house). In the rest of this post I will try to refer to work and tasks instead of stories and software to make it as generic as possible.

The benefits of small batches are:

  • Reduced amount of Work in Process and reduced cycle time. Since the batch is smaller, it’s done faster, thus reducing the cycle time (time it takes from starting a batch to being done with it, i.e. delivering it), thus lowering WIP, thus getting benefits from lowered WIP.
  • Decreased risk and variability. Since the batch contains less content, it’s by essence easier to control and validate. Delays are anticipated with more ease, quality issues are easier to spot, integration is done sooner. There is less chances for scope creep, since the batch stays “alive” for a shorter time (thus, ironically, large batches lead to even larger batches).
  • Increased Return on Investment. Suppose that you have two processes.
    • Big batches has batches built in 2 days that generate a daily $2 revenue.
    • Small batches has batches built in 1 day that generate a daily $1 revenue. Assuming a similar overhead, and absence of risk, while the final daily revenue generation is the same at a given point in time, Small batches provide a higher ROI since it starts creating value earlier on each iteration, as depicted below (vertical axis is revenue, horizontal axis is time in days).

Comparison of ROI in big vs. small batches

  • Reduced overhead. This may seem counter intuitive, since one might assume that the x% higher number of batches (smaller batches = higher number of batches) means that overhead is x% higher as well. But reducing the size of batches means reducing the associated overhead.
    1. The lower, more controlled level of risk is lessening the associated overhead of reporting and scrutiny
    2. The higher cadence requires a more streamlined final delivery process (e.g. pushing to production needs to cost $0 or be marginal) - meaning that the associated initial investment to lower the delivery process cost is then translated into lower total overhead (Assuming at 1 time, 2 days manual delivery by a resource costing $250 / day, or 25 times a delivery that uses 10 minutes of the same resource: 1 x $500 every month = $500 > 25 x $5.2 = @130)
    3. Lower cycle time associated with small batches means that each task is going to be under scrutiny less times (e.g. imagining a cycle time going from 10 days to 5, a given task will be reviewed 5 times instead of 10 → the overhead of reviewing it will be divided by 2).
  • Better prioritization. Since batches are smaller, it’s easier to prioritize high-value low-cost items first rather than having to prioritize batches bundling low-value items with high value items. It’s also easier to compare two smaller, more focused batches than big batches, since there are less issues to consider (e.g. should I redo the kids room or ours vs. should I replace the carpet in the kids' room by flooring or repaint our room - one embeds all sorts of issues, the other may be reduced to a utilitarian health + aspect for our kids vs. aspect only for us).
  • More iterations. By enforcing smaller batch size, feature scope is more decomposed, increasing the iterations necessary to build the feature, and thus another advantage is an…
  • Increased chance for an optimized feedback loop. Delivering more often, it’s easier to integrate feedback into subsequent batches, also linked with…
  • higher flexibility. Already-delivered-batches being smaller, the set of assumptions they are based on are smaller, and it’s easier to adjust it. This means that there are less chances that past work created something complex to change to adapt to current understanding (e.g. buying a house, redoing everything in it before moving in vs. buying a house, live in it for a while, then redo everything once you understand how the layout works for you).
  • More motivation and satisfaction. Smaller, more achievable and often attained goals are easier on stamina. There’s also an increased faith in what was achieved at delivery time, since it is smaller and has less, but more visible impact (and habits formed through delivering more often, decreases delivery anxiety caused by the fear of breaking something). Also see reducing WIP on getting less interruptions, finishing what was started, etc.

I got lots of inspiration from Principles of product development flow by Donald Reinersten, which I still highly, highly recommend.