WIP Limits: Flow Control, Not a Restriction

What is a WIP limit for?

WIP means work in progress: work that has started but is not finished. A WIP limit is the maximum number of items a team can keep open at the same time. In Being Agile, I mentioned in one sentence that most teams borrow the WIP limit from Kanban. This post is what that one sentence looks like in real life.

On paper it is a simple rule: “At most four items at a time.” When people first hear it, they think of it as a restriction: “What do I do if I have nothing to work on?” This question looks from the wrong side. A WIP limit manages work, not people. Its goal is not to keep everyone busy. Its goal is to make started work finish.

None of the 9 cards on our board was open because someone was lazy. Ahmet had sent his payment screen task to review and picked a new card while he waited. Mehmet’s card was waiting for the customer’s test environment, so he also picked a new card. Ayşe had two review requests, but she kept working on her own task because it also had to finish. Everyone made a sensible choice. Together, those choices produced a board that made no sense.

Little’s Law: first without the formula

A bank has one counter. The counter can serve 8 people a day. There are 40 people waiting inside. How many days will a new person wait? 40 / 8 = 5 days. It does not matter how hard the clerk works. The crowd inside and the speed of the counter decide the waiting time.

A software team works the same way. The open cards on the board are the crowd. The number of items the team finishes per day is the speed of the counter. A new card shares the team’s attention with all the open cards in front of it. The bigger the crowd, the longer each card lives.

Then with the formula

John Little proved this relation in 1961. In a stable system, average waiting time equals the average number of open items divided by the number of items finished per unit of time. With our numbers:

# Average cycle time = average open items (WIP) / items done per day (throughput)

# Early October (Sprint 9), no limit
# 8 cards done in 10 working days -> 0.8 cards per day
9 open cards / 0.8 cards/day = 11.25 days

# Late November (Sprint 13), flow limit 4
# 9 cards done in 10 working days -> 0.9 cards per day
4 open cards / 0.9 cards/day =  4.4 days

# Measured ("In progress" to "Done", average)
# before: 10.8 days    after: 4.5 days   -> the formula roughly holds

The first line made me uncomfortable. A new card took 11 days on average. Our sprint was 10 working days. So even an average card started on day one of the sprint did not finish inside the sprint. The answer to “Why do we always spill over?” was not in the quality of our estimates. It was in this division.

The formula has two levers: increase throughput or reduce WIP. Increasing throughput is hard and slow. You need more people, better tools or new skills. Reducing WIP is something you can do tomorrow morning. Also, when WIP goes down, throughput usually goes up, because there is less context switching and less waiting. For us it went from 0.8 to 0.9: small, but in the right direction.

One warning: Little’s Law talks about averages. It does not tell you when one specific card will finish. It also needs a stable system. If the amount of work grows fast in the middle of the sprint, or half the team is away, the numbers shift. That is why we measured 10.8 days while the formula gave 11.25.

How it should work

1. Put the limit on the whole flow

A card is not finished when it leaves “In progress” and enters “Review”. A card waiting in review or test is still open work. If you put the limit on only one column, the work slides into the next column and piles up there. Our limit applies to the sum of “In progress + Review + Test”.

2. Do not hide blocked cards; count them

A card that waits for an outside dependency may really be waiting. If you remove it from the limit, everyone learns to mark their card as “blocked”. Our rule: a blocked card counts toward the limit. On the day it gets blocked, we say its name and its blocker in the daily. If a card stays blocked for more than two days, removing the blocker is the first job of the day.

3. When the limit is full, look right

This is the main part of the rule. If the limit is full and your hands are free, you do not pick a new card. You look at the board from the right, just like the walk in Daily Standup:

• Is something waiting in the test column? Run the test scenario together.
• Is a PR waiting for review? Review it.
• Is a card stuck? Pair with its owner.
• Is a card blocked? You make the phone call to remove the blocker.

If none of these exist and the limit is still full, the limit is too tight. Then you do not quietly open a new card. You bring the number to the next retro.

4. Cards must be small

A limit of four cards does not help if each card takes a week. The team spends the whole sprint on four cards. The cards on our board are stories. Most of them are two or three days of work. Each one is split into tasks of one day or less, as in Epic, Story, Task. Small cards flow. Big cards block.

From the field: four, after three tries

7 October was day seven of Sprint 9. The next day we had the 40-minute argument from the Sprint Goal post. The sprint started with 11 cards (nine new, two carried over from the sprint before) and ended with 8 done. In the retro, the usual sentence came: “Our estimates are bad.” This time we did not look at estimates. We looked at the number of open items. Over the next four sprints we tried three different limits.

First try: 5 on “In progress”

This mistake was mine. I put the limit only on the “In progress” column. I chose 5 as “one item per developer”. We had five developers and one QA, so it looked reasonable. At the end of the sprint, nothing had changed. Cards left “In progress” quickly, because the limit was there. But 4 cards had piled up in “Review”. Total open work was still around 9. I had moved the problem one column to the right.

Second try: 3 on the flow

This time I put the limit on the sum of the three columns. To be bold, I chose 3. For the first time, the board looked clean. At the end of the sprint, cycle time was down to 3.3 days. I was ready to celebrate. Then in the retro Ahmet said: “When the limit was full, two urgent requests came from the customer. I did them without putting them on the board.” Mehmet and Ayşe had similar stories. We counted: five items had never reached the board.

So WIP on the board was 3, and real WIP was 8. The limit was so tight that people chose to become invisible instead of breaking the rule. This was worse than having no limit, because now the numbers were lying. Also, while two cards waited for the customer’s test environment, three people had nothing to do for half a day. There was no card they could help with.

Third try: 4 on the flow, one rule

We raised the limit to 4 and added one rule: no work happens off the board. If urgent work arrives, it gets a card, the limit goes over by one, and we say so in the daily. Hidden work dropped to zero, because there was no longer any reason to hide it.

The most important row is 27 October–7 November. Cycle time was at its best, and the period was the worst. If I had looked only at cycle time in that sprint, I would have declared success. I added the “work off the board” column after that retro. It is still the first column I look at.

In the last two rows, 5.1 and 4.5 days match the 5.0 and 4.4 days from Little’s Law. The gap is 0.1 days in both sprints. The formula started to fit the board, because the board now showed the truth. One note: in these measurements, “Done” still meant checked in the test environment. Since December, the Definition of Done has a production layer, so the same clock stops later. Numbers from that period cannot be compared with this table.

How it breaks

What to watch

• Number of open items, at the same time every day. You calculate the average from this.
• Items done per day (throughput). Per day, not per sprint. Little’s Law needs it.
• Cycle time. From the moment a card enters “In progress” until “Done”.
• Time blocked. The number of cards blocked for more than two days.
• Work off the board. One question in the retro: “What did you do this sprint without a card?”

Checklist

Conclusion

On the morning of 7 October there were 9 cards on the board and everyone was working. Effort was not the problem. The number of open items was. One division explained why our sprints always spilled over, better than all our estimation debates.

In the first two tries I chose the wrong place and the wrong number. The first moved the problem one column to the right. The second pushed work off the board. The right limit was the lowest number the team could follow without breaking the rule.

A WIP limit does not slow the team down. It slows down starting and speeds up finishing.