Over a million developers have joined DZone.

Pattern of the Month: Limited WIP

DZone 's Guide to

Pattern of the Month: Limited WIP

Limiting your WIP keeps the flow of your project consistent and prevents backlog items from depreciating due to a lack of demand.

· Agile Zone ·
Free Resource

Lean and Agile practice is founded on predictability based on evidence, and a timely response to demand which allows inspection and adaptation to occur. This greatly benefits from an even and consistent flow. For example, a team may encourage visibility over work that is done, in test, undergoing peer review, in progress, and which remains in their backlog. The team will organize themselves so that work flows between these stations as efficiently as possible and with minimal delay. Flow is brought about by encouraging "pull" across all stations in response to demand for completed work.

Image title

A customer or Product Owner, for example, ought to exert a demand for "done" work which is available for use. In order to be "done," however, work must be tested. Hence, demand will be propagated, or a "pull" exerted, on the testing station for work which is of acceptable and demonstrable quality. Only once this work has been satisfactorily tested can it be considered "done" and moved over to that station. This would make capacity available for more work to be brought into test. The pull-driven model has thus started to take effect. Moving work into "done" from "test" leaves a vacuum there, and this can only be filled by work which has been peer reviewed. The progression of reviewed work creates a vacuum at that station, which can only be satisfied by drawing off work that is in progress. A vacuum there will cause new work to be siphoned off the backlog. The use of "pull" in ensuring the timely actioning of work is therefore of critical importance. "Pushing" work onward before there is a demand for it will cause it to languish and depreciate in value, and waste will be incurred.

Achieving a smooth and even flow depends upon being able to limit "Work In Progress". Each station should be given some sort of limit, such that anything below the limit implies a potential for accommodating more work. If capacity is there, it will create the necessary vacuum for drawing work on from the previous station. Limited WIP has the clear advantage of reducing lead time, depreciation of stock-on-hand, and the cost of delay for each item being handled.

Most teams tend to model a backlog of work on the left hand side of a team board, and the various stations leading to "Done" follow successively to the right. Pull is exerted in the opposite direction, and hence a team board should be read from right to left if bottlenecks and other impediments to flow are to be properly understood.

Image title

There can, however, be problems in interpreting limited WIP in Scrum, because the Sprint effectively limits work in progress to the amount which can be accommodated within a Sprint time-box. Furthermore, at a finer level of granularity, each work item is not always a user story or similar requirement. The Sprint Backlog is a forecast of whatever work is thought necessary to accomplish the Sprint Goal. A Sprint Backlog item might therefore be a technical task.

Limiting WIP at each station to a certain number of tasks is certainly possible. A team might perhaps limit themselves to one or two tasks for a certain user story, complete them, and then move on to a task for a different story, before then moving on to a task for a third. However, this means that in effect multiple stories can be in progress and partially completed before even one story is "done" and available for demonstration and potential release. The final completion of any and all user stories could potentially happen in one go on the last day of the Sprint. Although this might defer significant risk to a very late juncture, and could well be sub-optimal, it would not break Scrum rules.

Scrum is a minimalist and non-prescriptive framework. A Development Team can plan a Sprint Backlog in terms of tasks or other items which can be actioned in any order they choose. It would be up to the team to decide whether or not this is the best way to accomplish the Sprint Goal, and whether or not to use a task-limited approach. A smooth task "burn-down" could indicate that technical risks are being managed. However there can be no empirical evidence of progress until valuable work - such as that expressed by a user story - has been completed and made available for use.

Limited WIP is Pattern of the Month at agilepatterns.org

Limited WIP

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


  • "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.

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.

Image title

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.

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.

See Also:

agile development ,agile patterns ,kanban ,limited wip ,kanban framework ,done

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}