Comparison
Batch sizevsWork-in-progress limit
Batch size
the release contained forty changes, something broke, and the first hour went on working out which one.
How much change moves through the pipeline at once. Almost every delivery improvement is a batch-size reduction in disguise, because small batches are easier to review, faster to test, cheaper to revert and clearer to attribute when they fail. The pressure is always toward larger batches, since each release carries fixed overhead, which is why the sustainable fix is to reduce that overhead rather than to exhort people to ship smaller.
Full entry →Work-in-progress limit
you were told to finish one of the four things you had started before picking up a fifth.
A cap on how many items may be in flight at once, per person or per team. It feels like a restriction and functions as a throughput improvement, because unfinished work delivers nothing while consuming attention, context and review capacity. It also makes bottlenecks visible immediately: when the limit is hit and nothing can start, the reason is the thing everyone was quietly working around.
Full entry →