Andrew Male

Through anecdotes and observation I know that limiting Work in Progress (WIP) is a good way for teams to focus on delivering stories and  ensure that bottlenecks don’t occur.  However, until recently I clearly explain why until I came across Little’s Law which states:

The long-term average number of customers in a stable system WIP is equal to the long-term average arrival rate, TH (Throughput), multiplied by the long-term average time a customer spends in the system, CT (Cycle-Time); or WIP = TH * CT.

Little’s law applies to all systems.  An example using Scrum might look like this:

1. 2 week sprint (10 working days)
2. 10 stories in the sprint

Assuming all stories are delivered in the sprint TH is calculated as stories delivered / time.  In this case 10 / 10 = 1.

If we’ve been imposing a WIP limit of 2 stories then we can calculate Cycle-Time: 2 / 1 = 2

In this example a story is in the system for 2 days. If we increase WIP then Cycle-Time also increases eg. 4 / 1 = 4.  Why should we care about this?  If our WIP limit is too high we will end up delivering most of our stories on the last day or two of the sprint.  We are then looking at big bang integration and other activities the Agile attempts to eliminate.

One possible reason for a burndown like the one above is that there was too much Work In Progress.  If 6 stories were in progress for a large part  of the sprint then CT becomes 6 days.  To achieve a burndown where stories are ‘done’ at regular intervals through the sprint we could take the following actions.  Limit WIP to a point where CT stablises around 2 or 3 days or improve Throughput by changing the process.

Scrum has two ceremonies where we can improve Throughput; the daily standup and retrospectives.  The standup is used to maximise throughput in the sprint and the retrospective for identifying process improvements to work on in the next sprint.

Until recently I thought that limiting tasks in progress was the throttle for WIP.  The trouble is that it’s still possible to  have a task in progress for almost every story in the sprint.  The correct way of limiting WIP is to use a meaningful unit of production. In Scrum’s case this is a story.