Work In Progress (WIP) | Agile Scrum Master
Work In Progress (WIP) is the set of started but unfinished work in a workflow, from the moment work begins until it meets the team’s done policy. Managing Work In Progress (WIP) reduces queues, context switching, and hidden rework, improving predictability, focus, and quality. High Work In Progress (WIP) usually increases waiting time and makes delivery less reliable, even when people appear busy. Key elements: clear start and finish states, explicit WIP limits, aging WIP signals, swarming to finish, and policies that prioritize completing work over starting more.
Work In Progress (WIP) and why it matters
Work In Progress (WIP) is the set of work that has started but is not yet finished according to the team’s done policy. It is a system property: it describes how much unfinished work exists in the workflow at a point in time, across design, development, testing, review, and release steps.
Work In Progress (WIP) matters because most delay in knowledge work is waiting, not active effort. When too many items are started, each item waits longer for attention, reviews, integration, decisions, or external inputs. Lowering WIP shortens feedback loops, increases transparency of blockers, and improves the team’s ability to deliver usable increments that can be validated with stakeholders and users, then adapted based on evidence.
Why measuring WIP matters
- Flow efficiency - Lower WIP reduces waiting and queues, which typically improves cycle time and reduces time-to-feedback.
- Quality - Fewer simultaneous items increases focus, reduces multitasking, and decreases hidden rework and defect injection.
- Predictability - Stable WIP supports more reliable forecasting because the system operates with less congestion and fewer late surprises.
- Team sustainability - Lower context switching reduces cognitive load and supports a sustainable pace under real constraints.
- Earlier learning - Completing work sooner enables earlier validation, clearer trade-offs, and faster adaptation of scope and approach.
WIP vs. WIP Limits
WIP is the actual number of items currently in progress, while WIP limits are explicit constraints on how many items can be in a given state at once. Limits are not the goal by themselves; they are a policy that makes overload visible and creates a decision point. When a limit is hit repeatedly, the response is to finish and unblock work, improve the workflow, or adjust policies based on what the data shows, rather than silently starting more work.
Work In Progress (WIP) start and finish definitions
Work In Progress (WIP) depends on clear definitions of when work starts and when it is finished. In many teams, start means an item moves into an active state such as In Progress, and finish means the item reaches Done in a usable state. If your workflow includes queues for verification, release, or external approval, decide explicitly whether those states count as WIP or as downstream waiting that still delays outcomes.
Useful policy choices for Work In Progress (WIP) include:
- Start point - The moment the team commits capacity and begins active work on the item.
- Finish point - The moment the item meets the done policy, not the moment it is handed off to another queue.
- Work item type - A consistent unit such as a ticket, story, or service request, with rules for splitting and merging.
- Workflow states - Explicit states that reflect reality, so WIP counts are observable facts rather than opinions.
Work In Progress (WIP) and queuing effects
Work In Progress (WIP) creates queues. When the system has more started work than it can finish smoothly, items wait in progress. This waiting increases cycle time and makes delivery less predictable. A common symptom is a board full of “nearly done” items while very little reaches Done.
Because variability is normal, WIP is best treated as a working range rather than a single “ideal number.” The aim is to keep WIP low enough that work finishes frequently and feedback arrives quickly, while still handling necessary interrupts and different classes of service without destabilizing the system.
A practical relationship is that, for a given completion rate, higher WIP tends to increase time to finish. Many teams validate this with their own data by comparing WIP levels to cycle time distributions and by watching how aging work behaves when policies change. If WIP rises but throughput does not, the system is usually accumulating delay rather than accelerating value delivery.
Typical sources of rising Work In Progress (WIP) include:
- Oversized work - Large items stay open longer, increasing partial completion and obscuring real progress and risk.
- Decision latency - Waiting for clarifications, approvals, or stakeholder input keeps items open and congests downstream states.
- Specialist bottlenecks - Reviews, testing, security checks, or deployment steps accumulate when capability is constrained.
- Starting too much at once - Pressure to appear busy increases multitasking, handoffs, and queueing.
- Unclear priorities - Frequent priority shifts lead to starting new work without finishing existing items.
- Dependencies - Waiting on other teams, systems, or vendors causes partially completed work to accumulate.
Managing Work In Progress (WIP) with explicit policies
Managing Work In Progress (WIP) requires explicit policies that prioritize finishing. A WIP limit is one mechanism, but teams also need policies for pulling work, handling blockers, and treating urgent items without turning everything into urgent work.
Common policies for managing Work In Progress (WIP) include:
- WIP limits - Explicit caps per workflow stage that prevent overload and encourage pull-based flow.
- Stop-start rule - When a limit is hit, the team stops starting new work and focuses on finishing or unblocking.
- Swarming - Temporarily reallocating people to finish stuck items instead of starting additional work.
- Definition of done - Ensuring Done includes integration and verification so unfinished work stays visible and does not become hidden downstream.
- Classes of service - A small set of urgency policies to handle truly time-critical work without collapsing flow for everything else.
In Scrum contexts, these policies support the Sprint Goal. Even with clear Sprint scope, high WIP can prevent completion of a usable Increment because integration, review, and testing become late bottlenecks. Managing WIP increases the probability of finishing valuable work earlier, learning sooner, and adapting within the Sprint rather than discovering problems at the end.
Signals from Work In Progress (WIP) and aging work
Work In Progress (WIP) is a diagnostic lens. If WIP is high and items are aging, the system is signaling a constraint. Combine WIP with aging work signals, blocked time, and cycle time trends to decide where to inspect and what to change.
Practical signals related to Work In Progress (WIP) include:
- Aging WIP - Items that remain in progress longer than typical indicate blockers, unclear slicing, or hidden dependencies.
- Blocked time - Persistent blocked items point to external constraints or unclear escalation and decision policies.
- Work piling in one state - Accumulation in review, test, or deploy indicates a bottleneck that may require policy, tooling, or capability changes.
- High carryover - Many items not finished in a timebox often indicates oversized work, too much WIP, or weak integration practices.
- Unstable flow patterns - Frequent surges and drains can indicate batching, late handoffs, or policy churn that reduces learning.
Misuse of Work In Progress (WIP) and practical guardrails
Work In Progress (WIP) is often misused when it is treated as an individual utilization problem or a compliance target. That drives local optimization: people start more work to look busy, which increases queues, delays feedback, and reduces completion. WIP helps when it is used to improve the system and the outcomes it produces.
- Maximizing utilization - Looks like keeping everyone busy at all times; it hurts by increasing waiting and multitasking; do instead optimize for finishing and fast feedback by keeping WIP within a sustainable range.
- Hiding unfinished work - Looks like moving items forward to make the board look clean; it hurts by hiding risk and delaying learning; do instead keep partial work visible and make blockers explicit.
- Individual WIP targets - Looks like assigning WIP goals per person; it hurts by encouraging fragmentation and gaming; do instead manage WIP at team and workflow level through policies and constraint removal.
- Lowering the done standard - Looks like reducing quality to “finish faster”; it hurts by creating rework and unstable throughput; do instead reduce batch size and queues while protecting the done policy.
- Using limits as mandates - Looks like treating a limit breach as failure; it hurts by discouraging transparency; do instead treat breaches as signals to inspect demand, workflow design, and constraints, then adapt.
Examples and patterns
A common improvement pattern is to reduce Work In Progress (WIP) gradually and observe the impact on cycle time, throughput stability, quality, and customer feedback timing. Teams often start by limiting the most constrained stage, then extend policies upstream. Another effective pattern is “finish first”: a daily discipline that no new work is pulled until the oldest item is unblocked or finished.
When WIP is managed well, teams typically see more frequent completions, fewer late surprises, and better ability to respond to change. The purpose is not to make WIP small for its own sake, but to create a system where learning and delivery happen quickly and reliably, and where progress is judged by working outcomes rather than the volume of started work.
Work In Progress (WIP) is the set of started but unfinished work items, managed to reduce queues and context switching and improve predictability and quality