Lean and Agile practice are evidence-based and rely on the empirical delivery of value to assure predictability. Planning, development, and incremental release ought to occur on a short enough timescale, or cadence, to facilitate the inspection and adaptation of both product and process.

The even and consistent flow of work underpins this ability. Flow is enabled by a clear demand for completed work, the "pull" being propagated as efficiently as a team can manage across all of the stations at which value is added. Limiting "Work in Progress" helps to achieve this flow, and it is a very important skill to master. It ensures that work must be completed before anything new can be started. Each station should be given some sort of limit, such that anything below the limit indicates a capacity for new work to be brought forward. This helps to build pull across the value stream.

Limited WIP reduces lead time, cost of delay, and the depreciation of work has been commenced but not finished. Problems can arise when WIP is not subject to a clear limit. New work may be pushed or forced onto a team in an attempt to drive it through their engineering process, a common situation in a reactive environment where product ownership and backlog management is weak. Furthermore, team members may be keen to show they are "busy" and that they have a lot of work on their plate. This antipattern can require deep cultural change before it is resolved and flow is enabled.

A team with unlimited WIP may exhibit the following characteristics and constraints:

• Not everything in progress might be underway. The transparency over the work people are genuinely doing may, therefore, be poor.

• Much of the work that is thought to be in progress may, in fact, be blocked due to external dependencies, such as a need for certain skills or authorizations which the team does not have in order for work to be completed.

• Some of the work being performed may not be aligned to the Sprint Goal.

• The team boundary may be poorly defined or unstable, such that it is unclear who is committed and who isn't.

• The items in progress may not have clear acceptance criteria, and the point at which they are considered to be "Done" may be indeterminate.

• The items in progress may not be independently valuable and effectively constitute a batch.

Unlimited WIP

Intent: Start new work before current work is completed

Proverbs: "More haste, less speed."

Also Known As: Unbounded Commitment

Motivation: When faced by competing and vociferous stakeholder demands, team members can feel obliged to action multiple items simultaneously. In an attempt to pacify stakeholders, they can, therefore, claim that an item is being worked on and is no longer enqueued.

Structure: A development team accepts items that have been enqueued in an ordered backlog. There is no limit to the number of items that are allowed to become a work in progress.

Applicability: Unlimited WIP is common in reactive environments where product ownership is weak and/or scattered, such that no effective backlog prioritization occurs.

Consequences: Having no limit on inventory increases batch sizes and reduces the prospects of incremental release. Work depreciates while it remains in progress, and the timely delivery of value is compromised.

Implementation: Lean Kanban methods explicitly limit Work in Progress.  Note that WIP limits may be applied to each Kanban states where work may become enqueued. Scrum does not strictly require WIP limits to be enforced as batch sizes are constrained in the form of Sprint Backlogs. Unlimited WIP is discouraged in all agile methods.

See Also: Limited WIP, Single Piece Flow