Don Reinertsen gave a great keynote address at YOW 2012 entitled The Practical Science of Batch Size. I recommend watching the video when it’s posted, probably in January. In the mean time, I want to relate one small illustration from the talk. It’s a parable of why agile methods can save money.
Someone generates a two-digit number at random. You can pay $2 for a chance to guess the number, and if you are correct, you win $200. It’s a fair bet: both sides have net expected return zero.
Now let’s change the rules. Same reward, but now you pay $1 to guess the first digit and you find out whether you were right. If you were, you then have the option of spending another $1 to guess the second digit. Now you have a winning bet.
Your chances of winning are the same as before: there’s a 1% chance that you’ll win $200. But the cost of playing the game has gone down. There’s a 90% chance that you’ll spend $1 and a 10% chance you’ll spend $2. So your expected return is $2, but your expected cost is $1.10, so on average you make $0.90 every time you play the game.
Don argues that we often come out ahead by doing things in smaller batches: committing less money at a time, taking on smaller projects at a time, etc. Not that smaller batches are always better. As batch sizes decrease, holding costs decrease but transaction costs increase. You want to minimize the sum of holding costs and transaction costs. But we more often err on the side of making batches too large.
In the example above, the batch size is how much of the number we want to guess at one time: both digits or just one. By guessing the digits one at a time, we reduce our holding cost. And in this example, there are no transaction costs: you can guess half the digits for half the cost. But if there were some additional cost to playing the game — say you had to pay a tax to make a guess, the same tax whether you guess one or two digits — then it may or may not be optimal to guess the digits one at a time, depending on the size of the tax.