Count the work, then limit it

A team with too much to do usually does the natural thing: it starts more of it. Every item someone picks up is visibly “in progress”, the board fills, and it feels like the team is moving. Whether it is moving any faster is a different question, and it has an answer you can measure.

Four numbers, defined once

The Kanban Guide, by Daniel Vacanti and Jim Coleman, defines four flow measures. They are worth learning exactly as written, because the lab below implements them that way:

• WIP: “The number of work items started but not finished.”
• Throughput: “The number of work items finished per unit of time. Note the measurement of throughput is the exact count of work items.”
• Work Item Age: “The elapsed time between when a work item started and the current date.”
• Cycle Time: “The elapsed time between when a work item started and when a work item finished.”

Notice what is not on the list: points, hours, estimates. Throughput is a count of finished things. Nobody can make it go up by estimating harder.

“Kanban” names more than one thing, so say which you mean. The Kanban Guide is one document. Kanban University’s Kanban Method is another, with its own practices. There is also an “Open Guide to Kanban” fork. This lesson uses the Kanban Guide’s definitions.

Little’s Law, as Little wrote it

The three measures are tied together by an identity called Little’s Law: average WIP equals the arrival rate times the average time in the system, usually written L = λW. John Little proved it in 1961. In a 2011 retrospective he showed that, measured over a finite window, it “holds exactly even if the queuing system is never empty”. In that version L is the area under the WIP line divided by the window’s length, and W is that same area shared out over the items that were present, so the identity is true by construction.

Little was also clear about what it is for: “we are in the measurement business, not the forecasting business.” Little’s Law describes what you measured. It doesn’t promise what happens when you change something.

Daniel Vacanti makes that point with an example. A team averages 20 items in progress, a 5-day cycle time and a throughput of 4 a day. Doubling WIP to 40 does not double throughput to 8. “All Little’s Law will say is that an increase in average WIP will result in a change to one or both of average Cycle Time and average Throughput.” If the team’s capacity hasn’t changed, it is cycle time that changes.

Try it

The lab is a board with four people who can each do one unit of work a day, and at most two people on any item. The sizes of items and how fast they arrive are invented. Cycle time is never calculated from Little’s Law: it comes out of who works on what.

Because Little’s identity is true by construction, checking it proves nothing on its own. So the lab adds a check of its own, not Little’s: it counts item-days twice, once from the board’s WIP each day and once from every item’s own start and finish, and shows both totals. If they ever differ, the records have lost an item.

Where the queue went

With no limit, every arriving item was started the day it arrived, then waited on the board while the team worked on older ones. That waiting time was counted as cycle time, and as age on the board. With a limit of four, the same items waited in the backlog instead. The team finished just as many, because nothing about their capacity changed. The difference is that the work in progress now meant what it said: being worked on.

Push the limit too low and the trade flips. With a limit of one, only two people can work, the other two sit idle, and throughput drops by about half. A lower WIP is better only while there is enough started work to keep everyone busy. That’s the “one or both” in Vacanti’s sentence.

A measured case, read carefully

At BBC Worldwide, a nine-person team’s mean lead time fell from 22.8 to 14.4 working days, about 37%, between October 2008 and October 2009, and the upper control limit of its lead times fell from 70.7 to 37.3 days. It is a real measurement, and it is one team. WIP limits came with smaller work items (the share of small features rose from 52% to 75%), visible boards and a team whose skills were growing. The study can’t say which change did what. Read it as “this happened here”, not “WIP limits cut lead time by 37%”.

Forecast with percentiles, not averages

The Kanban Guide asks for a service level expectation: “a forecast of how long it should take a work item to flow from started to finished”, given as an elapsed time and a probability. “85% of items finish in 10 days or less” says something an average cannot: how bad the slow ones get. The lab draws that line on the cycle-time chart. When the dots stay under it, the team is keeping its own forecast.