Limited WIP

Applicability: Limited WIP is applicable to all Business As Usual workstreams. It may also be applicable to project work, although the WIP limits can be overridden or changed by an incremental delivery plan.

Consequences: The limitation of WIP will allow value to be delivered earlier, and there will be less stock-on-hand that will be subject to depreciation. Throughput and forecasting will improve. For projects, the risk of failing to meet a Sprint Goal will be reduced as less work is likely to remain in progress by the end of the iteration.

Structure: Each backlog item that is currently being worked on by a development team will count as Work In Progress, and the total count will not exceed the established WIP limit.

Intent: Minimize stock-on-hand so as to deliver value more quickly and reduce waste

Proverbs:

Don’t bite off more than you can chew
Givers have to set limits because takers rarely do

Also Known As:

Lean Pull

Motivation: The pressure upon teams of finite size to respond to unconstrained demand can lead to excessive work in progress. The result is that the delivery of any one item becomes delayed as attention shifts to another, and the value invested is given an opportunity to depreciate. By limiting the amount of work that can be progressed at any one time, this problem is mitigated and the problem is reduced to one of backlog prioritization and quality of service.

Implementation: Limited WIP is a key feature in all Kanban and Lean configurations. It is possible for a Scrum team to plan to action all of a Sprint Backlog in one go, and not limit work in progress. However, this is considered bad practice as it defers acceptance of multiple items to the end of the Sprint, and thereby increases the risk of failing to meet the Sprint Goal. A limitation of WIP is therefore also considered to be good (if not essential) practice in Scrum.