Daily Archives: 23.02.2012

Software Engineering

Understanding the WIP Limit and Impediments in Scrum

Scrum and Agile software development is actually based on Lean production management and Queueing Theory, having a mathematically proven basis. Understanding the basic queueing model concepts leads in better understanding of Scrum practices. Historically Lean manufacturing was based on Fredrick Taylor’s work on Scientific Management in the 1910′s , Henry Ford’s Mass Production and in the 60′s Toyota Production System. In Computer Science the Lean principles seem to lag 20 years the manufacturing, but now it’s time to wipe the dust off the 80′s Lean books (like The Goal ).

Why WIP should be limited?

The key adaptation of software engineering agile methods to the traditional Lean is introduction of Iterations or Sprints to reduce the Work In Progress (WIP). While in manufacturing the work pieces are constant and multiple, in software engineering the task sizes can vary wildly from half an hour to several months. The idea of the iterations is to detect the too large tasks and split them into smaller, more manageable pieces. Scrum uses estimation methods like Planning Poker and Sprint Planning Meeting to detect stories that are too large to fit in one sprint. A too large story should be split into two smaller stories. The key concept that is often missed is the Project Velocity, which means the number of tasks completed in the previous sprint. If you got 6 stories done previously, you should WIP Limit the backlog for the next sprint to 6 stories (or story points). If the practices of Project Velocity WIP Limit on Backlog and splitting of the too large tasks is taken lightly, the danger is that the team fails to deliver anything at all (I’ve seen it actually to happen).

The Optimum WIP Limit = 1

A mathematical proof applies to Scrum WIP Limitation stating that the optimum WIP limit = 1 task per coder (or tester, or analyst) called Little’s Law :

L = λ W, where

L = WIP (number of tasks in a system)
λ = Project Velocity (arrival rate of tasks or throughput)
W = average time to complete one task (cycle time)

It’s maybe more intuitive to relabel the formula as

Cycle_Time = WIP / Velocity

This has some profound implications, since we can see that

  • if WIP = 4, the Cycle Time to complete one task is Cycle_Time = 4 / Velocity.
  • however, if we limit the WIP = 1, the Cycle time is Cycle_Time = 1 / Velocity, which is four times smaller than when WIP=4.

The Little’s Law says that the optimum WIP is 1 to the tasks completed in the fastest possible time. In other words, you should do only one task at a time for maximum performance, multi-tasking makes your total productivity slower. If you have two coders, the WIP Limit can be 2. Having more than one coder leads into interesting increases in working efficiency that can be modeled by the Erlang’s Blocking Formula (I’ll write more on this later).

Impediments are not WIP

Another concept that is widely not understood (or not used) is the Impediment, or a blocker that prevents you from proceeding a task. It has to be stated that almost none of the Task Management softwares support management of Blockers in a proper fashion, except our pure lean task management application http://tee.do , which was specially designed to support the Lean process. For proper management of WIP Limit and for maximum performance, the impediments must be removed from the WIP queue, and placed in a separate queue, or state. When a coder stumbles into a blocker (e.g. lack of specification, servers are down etc), he should tag the task as Impediment, and start working the next highest prioritized task on the TODO backlog.

The key top priority task of the Scrum Master is actually to daily fight to solve the blockers as quickly as possible, by facilitating the customer to give more accurate specification, buying licences, fixing the version control etc. This is actually the same process than managing the Critical Path in traditional project management, except the problems are not analyzed in advance, but reacted to as they occur (maybe there would be space for risk management planning in agile, too).

By separating WIP tasks from Blocked tasks, the WIP Limit can be adhered and the maximum performance of the team maintained. When an impediment is resolved, it should be placed back on the top of the TODO Backlog as the highest priority, to ensure that the task currently in WIP can be completed in minimum cycle time. In some situations the blocked tasks are of so high priority that they need to be worked immediately when the Impediment is resolved, but this leads into reduction of total efficiency and increased cycle time.

Reducing Waste by Releasing Often

The concept of WIP Limit is actually one key method to Reducing Waste in Total Quality Management. The idea is to minimize the working capital employed by the unfinished work. In manufacturing this means reducing the size of the warehouse, but in coding it means Releasing Often and using methods like Continuous Integration. The Release Cycle of one year leads into the waste of paying the salaries of the coders for 12 months without having the system in productive use (can be hundreds of thousands or more). On the other end of the spectrum is Kanban and releasing upgrades to the software several times per day, immediately when a task is completed and tested (reducing the waste to only tens or hundreds of EUR/USD).


To understand the practices of Agile ways, it is beneficial to know the basic principles of the Queuing Theory. The Little’s Law states that the you should limit your work in progress to 1 task at a time per coder. To achieve the maximum productivity you should do only one task at a time. It is crucial to also understand that if the progress of the task is blocked, it should be removed from the WIP list, and have the Scrum Master to resolve the Impediment as quickly as possible. The maximum total efficiency of a software engineering process can be achieved by applying the same principle also on the big level by releasing the feature immediately once it has been completed, even several times per day.

Published by: