Small batch sizes - how small is small?

Many agile, continuous delivery and lean practitioners advocate only pushing small batches through your delivery process at any one time. The benefits of doing so have been described in detail many times, with Eric Ries giving a great overview.

Essentially the benefits are:

• Faster feedback 
• Problems are instantly localised 
• Reduce risk 
• Reduced overhead 

How small is small?

One thing that I don’t often see articulated in too much detail is what a small batch size actually looks like or means.

Its Relative..

That’s right, its really relative to your current state. Small batch sizing is about continually optimising your manageable workload until you get to the point when the benefits described are realised.

A small batch could be any of the following:

• Enough lines of code to enable a particular method call 
• A feature branch 
• A service 
• An individual component 
• A change or changes that take days or short amount of time to produce 

The important thing to remember is that it really is relative to what you may have been or are doing at a given point in time. If you are pushing thousands of lines to production during a release, and then you gradually reduce that to hundreds, then your batch size is relatively small, and you have probably received many of the benefits associated with small batch sizes. If any of the above are giving you some or all of the benefits mentioned then you are probably pushing relatively small batch sizes through your system.

As a rule of thumb, small batch sizes are not typically associated with:

• Making changes to multiple parts of a system 
• Delivering big feature sets that typically move you to a major version release 
• Delivering multiple components 
• Multiple changes to a database 
• Changes that take many iterations 

Although your customer might not be ready or have a need to receive smaller incremental updates, that does not stop you from delivering in that way to a pre production platform or similar.