How reducing your batch size is proven to radically reduce your costs

Do you work in an organisation struggling to do more with less? We come across many projects where organisations have tossed in additional resources to meet a looming deadline, pinching pennies from elsewhere and creating stress for all, without solving the underlying problem of how to deliver faster, cheaper and better.

If you want to deliver faster, cheaper and better, you need to reduce your batch size.

Working with small batch sizes (a batch is a unit of work that passes from one stage to the next stage in a process) has tremendous impact. It improves flow and lets us deliver quickly and reach project completion earlier.

In software development terms, a traditional process means a team will define all of the project’s requirements first, complete all of the design next and then finish all of the coding before testing.

In contrast, working in small batch sizes means completing, for example, 10% of the design, the development and the testing before moving on to the next 10% of the product’s features.

Why is batch size important?

There are very good reasons why batch size is important.

First up, when we work with small batch sizes, each batch makes it through the full lifecycle quicker than a larger batch does. We get better at doing things we do very often, so when we reduce batch size, we make each step in the process significantly more efficient.

Smaller batch sizes also mean you’ll deliver faster and reach project completion earlier. Since work on a feature isn’t complete until it is successfully running in production and generating feedback from customers, large batch sizes delay that essential feedback.

Batch size can be one of the most difficult things to optimise but it is economically crucial. Numerous studies have proven that larger batch sizes lead to longer cycle and delivery times – and a longer wait to find out if you’ve delivered value to your customer.

batch size

Faster, cheaper, better

There’s a bunch of beneficial outcomes that come from working with much smaller batch sizes than traditional processes recommend.

Some of these benefits are:

  • faster feedback – the sooner you pass on your work, the sooner you’ll know if there’s an error
  • better feedback – you’ll know earlier on if you’re building the right product, because you’ll get it in front of your customer sooner
  • greater visibility – bottlenecks and inefficiencies are clearly seen
  • improved quality – and when quality goes up, efficiency increases and team morale goes up too
  • less risk of delays and cost overruns – the larger the batch, the more likely you’ve made a mistake in estimating or in doing the work, and the likelihood and impact of these mistakes increases as batch size grows
  • reduced complexity – you’ll reduce the amount of complexity that has to be dealt with at any one time by the team
  • improved decision making – it’s easier to make business and technical decisions and recover from mistakes.

All this makes for better economics. Donald G. Reinertsen’s diagram uses testing as an example, and shows the direct links between a smaller batch size (which results in smaller changes, fewer open bugs and faster cycle times) and improved economics.


Smaller batches = greater output

We’ve even got mathematical proof that you should reduce your batch size!

First published in 1954 and proven in 1961, Little’s Law has been used across many industries. At its heart, it deals with queuing systems, which is what coding-oriented projects also have to deal with. Little’s Law means that if you reduce your cycle time by the power of 10, you increase your capacity/production by a power of 10.

Tips for reducing your batch size

What is an ideal batch size, and how do I reduce my current batch size?

Reinsertsen recommends reducing your batch size by 50%. You can’t do much damage in this range, and the damage is reversible. Observe the effects, keep reducing, and stop reducing when total cost stops improving

Batch sizing is very much a horses for courses endeavour. Some large projects might favour a 30 day sprint, but for most of the projects we’re involved in, we’ve found the sweet spot is two weeks.

If you’re using Agile, you should be working with small batches already. (If you’re trying to implement Agile but using the same batch size as a traditional project – that is, 100% – Agile will not work!) However, it’s important to remember these guidelines when you’re setting up your next project:

  • reduce the timeframe for delivering results
  • don’t define all your requirements and success criteria in one go
  • prioritise your product’s features and begin with the smallest amount of work that will still deliver value to your customer
  • test and release as soon as that work is complete – adopt continuous integration and ensure deployment and testing efforts are ongoing during your project.

The last word goes to Reinertsen and his video: The practical science of batch size. It has all you need to know about batch size – how it works, why it works and what to do next.

Prioritising versus ordering: what is the difference and why does it matter?

Deciding on the most important thing to work on at any given time is not an easy task for a project team, but it is one of the most important decisions that needs to be made, many times over, from the start of a project through to its end.

A few years ago I was tasked with being the Scrum Master on a project that had a huge amount to get through in a short period of time.

There were many perplexing elements to the project, but one of the most perplexing was that the team had prepared around 400 user stories, all written to varying degrees of detail. I would have hoped for scant detail on each, followed by a prioritisation exercise and a couple of sessions to expand on the most valuable stories.

However, we were asked to flesh out, estimate and order all 400 before the first sprint.

We spent three agonising days refining the backlog. I suspected most of this work would be of little use as many things would change as soon as the first sprint was underway.

I also attempted to run a prioritisation exercise, and I learned pretty quickly that the word ‘prioritisation’ was frowned upon, and the term ‘ordering’ was preferred.

But what’s the difference?

Prioritising, in the Agile world, focuses on identifying the business value of each story, doing the most valuable work first, delivering quickly to get feedback and then reprioritising the remaining work based on what we’ve learned.

Ordering is a type of prioritisation, but it’s based on an assumption that we already know everything we need to know about our project. In this case, ordering meant that every story was of equal value because every story absolutely needed to be completed for the project to be considered a success.

I have never come across a project that couldn’t be broken down and prioritised by value. It isn’t always easy, but it is always necessary. Without truly prioritising, the team runs the risk of building features that no one will actually benefit from, and working without any useful feedback on what was delivered earlier in the project.

Assuming everything is equally as valuable is sure to result in both time and budget running out before we deliver the most important benefits to the user.

Have you ever faced a prioritisation challenge? Has someone in your team, or maybe at executive level, advocated for their own pet part of a project over what is really valuable to the customer? Have you disagreed with your colleagues about what should be done first?

Be prepared to make those hard (but ultimately satisfying) decisions, because prioritisation drives your team’s performance and ultimately ensures you deliver value to your customer.

To find out more about prioritisation, come along to our Agile Professional Foundation two-day course with certification.

3 top tips to set up your project for success

Over the last 10 years, I’ve seen the differences between projects that start from a good place and those that don’t. After analysing the patterns, I’ve distilled it down to three critical things that will reduce your risk and give your project the best chance of success.

1. Partner with […] Continue Reading…

Mindfulness and Agile – different sides of the same coin?

At face value there would seem to be no connection between Agile and mindfulness. After all, Agile is a project management methodology while mindfulness is a mental state of awareness.

But I really see a lot of cross-over connection between the two disciplines.

When you practice meditation, you’re being mindful. Your […] Continue Reading…

Railsn00bs gets a boosted presence

Taylor’s flatmate wanted a different meeting space for the Railsn00bs October meet-up, so Taylor put forward Boost’s office for the gathering and co-hosted the four-hour Saturday afternoon event of 15-30 developers.

There are about 200 people on the meet-up mailing list for Railn00bs. The October session was the eighth meet-up for the group, […] Continue Reading…

Waterfall and why it’s not suitable for software development

The whole controversy over Agile vs waterfall methodology has been covered in countless articles and blog posts. Yet I still spend a lot of time explaining the challenges and reasons why I think running a waterfall approach in software development projects is not a good idea.

In this blog post I will explain a […] Continue Reading…

Agile transition – workshopping the roles

When going through an Agile transition, companies face all kinds of challenges. One of the biggest challenges is getting everyone on board and excited about the transition. During the transition at my previous employer in Berlin I talked to many colleagues who raised concerns. I did lots of one-to-one meetings trying […] Continue Reading…