In my last blog post, I discussed how stopping multitasking (aka single piece flow) can increase the throughput of deliveries. This by itself can in turn increase productivity; but only if the deliveries have value.  Later articles on Priority Setting and Value will focus there. Before that I want to discuss another way to increase throughput. This article is about the relationship of batch size to through-put. What I am discussing applies to batches or anything; sprint backlog, product backlog, points in a story, MVP size, or order size at a drive up window. My through put I mean how many units of value can be delivered in a set time.

To demonstrate this we usually play with pennies.  We form teams of 5 (4 workers and one timer). The 4 workers “process” the pennies. Processing means to flip the coins and record the result then passing them to the next team member. The 4 people are each one step in a 4 step Value Stream. A Value Stream is a way of thinking about the chain of steps in any enterprise from an idea to cash. Traditionally software products may have Design, Develop, Test, Deploy for example.

In the first round we simulate using a batch size of 10 pennies.  The team member in the 1^st position flips each of the ten coins one at a time and records the result. When they are finished with all 10, all 10 are passed to the next team member who repeats the processing. This is repeated down the line until all 10 coins are processed through all 4 steps. The timer times from the first flip in the chain until the last flip at the end is complete.

In the second round we use the same 10 pennies but this time we set the batch size to 1. So the fist team member flips one coin, records the result, passes the coin to the next person, and pulls another coin. The timer times from the 1^st flip to last at the end of the value stream.

Although your results may vary some, generally most teams end up like the table below;

This is the very same amount of work done 3 to 4 times faster or the more stuff delivered for the same time.  The only change was reducing the size of the work unit. No one worked faster. In fact, most people that work with single piece flow feel better. This does not happen from heroics or magic. Its better than that; its math.

In Lean, this phenomenon demonstrates Little’s Law. Little’s Law relates WIP with Cycle Time and Through-put like this;

Cycle Time is also often thought of as wait time. This how long you would have to wait if you requested something in this system from the start to exit. Here is an online calculator that solves for any 3, if you are interested in the math Littles Law Calculator

Some common ways we add WIP include;

1. Multi-tasking
2. Big work units (MVPs, Stories, Goals, Improvements, Projects, batching things up, etc.)
3. Adding Steps to a Value Stream (Work-arounds, approvals/sign offs, etc.)
4. Non-value added activity (Busyness, status reporting, unneeded documentation)

So summing up; by focusing on one thing and working on the smallest things possible we can deliver things our fastest.

Some things to think about;

1. If you are a requester, how does the size of your request affect your wait? Would you break your ask into smaller pieces if you got them faster? Does the fear of not getting anything cause you to ask for a bigger batch?
2. If you take requests (especially from more than one source), how can limiting the size of any request help you make sure you serve everyone as fast as you can? What can you do to help protect your through-put?
3. If you are on a scrum team, would you rather the Sprint Plan have one 13 point story, or split it into 5, 3 point stories? Which plan is less risky?
4. What behaviors and skills to you need to collaborate with customers to maximize throughput? How to we organize, empower, and coach to increase these capabilities?