Work in progress (wip)
Work in Progress (WIP) measures how many work items have been started but not yet completed at any given moment. In software development, this might be features in development, bugs being fixed, or stories being implemented. WIP is a fundamental concept in lean and agile methodologies because it directly affects how quickly work flows through a system and how predictable delivery becomes.
Why it matters
WIP matters because of a counterintuitive truth: starting more work often means finishing less. When teams juggle many items simultaneously, each item takes longer to complete. Context switching burns time. Partially done work sits idle waiting for attention. Dependencies create bottlenecks. Meanwhile, nothing actually ships.
Understanding and managing WIP helps teams:
The math behind wip
Little's Law, a fundamental principle of queueing theory, explains why WIP matters:
Average Lead Time = Work in Progress ÷ Throughput
This means that if your throughput (work completed per unit time) stays constant, reducing WIP directly reduces lead time. Halve your WIP, halve the time from start to finish.
Conversely, increasing WIP without increasing throughput (which rarely happens - usually throughput decreases) extends lead times. Starting more work slows everything down.
Types of wip
WIP appears at multiple levels:
Individual WIP. How many tasks is one person working on simultaneously? High individual WIP fragments attention and reduces effectiveness.
Team WIP. How many items is the team working on together? High team WIP spreads thin resources across too many fronts.
System WIP. Across the entire development pipeline - from idea to production - how much is in flight? High system WIP creates long queues and unpredictable delivery.
Each level matters, and problems at one level often indicate problems at others.
The problem with high wip
High WIP creates cascading problems:
Context switching costs. Every switch between tasks burns cognitive energy and time. Studies suggest 20-40% productivity loss from frequent switching.
Longer feedback loops. When work takes longer to complete, feedback on whether it's correct takes longer to receive. Mistakes compound.
Hidden blockers. With many items in progress, it's easy to move to something else when blocked. The blocker never gets resolved because there's always something else to do.
Staleness. Work started months ago but not completed becomes outdated. Requirements change, code diverges, context is forgotten.
Stress and unpredictability. Teams with high WIP feel constantly behind, unable to say when things will be done. This creates stress and erodes stakeholder trust.
Visualizing wip
Kanban boards make WIP visible:
When a team sees twenty cards in the "In Progress" column, the problem is obvious. This visibility enables management.
Managing wip
Several practices help manage WIP:
Stop starting, start finishing. Before pulling new work, focus on completing what's already started. Resist the temptation to begin something new.
WIP limits. Explicit caps on how many items can be in progress at once. When the limit is reached, no new work starts until something finishes.
Pull systems. Instead of pushing new work onto teams, let teams pull work when they have capacity. This naturally limits WIP to available capacity.
Focus on blockers. When WIP can't decrease because items are blocked, the blocker becomes the top priority. Resolving it unblocks flow.
Smaller batches. Breaking work into smaller pieces means each piece completes faster, naturally reducing WIP.
Wip and agile practices
WIP concepts integrate with agile methodologies:
In Scrum, sprint capacity planning implicitly limits WIP. Teams commit to what they can finish, not what they can start.
In Kanban, explicit WIP limits are central to the method. Columns have maximum card counts that cannot be exceeded.
In Lean, WIP is a form of inventory - waste that should be minimized. "Just in time" delivery means starting work just before it's needed.
Regardless of methodology, the principle holds: limit how much you start to increase how much you finish.
Wip in product management
Product managers encounter WIP at the roadmap level:
High organizational WIP creates the same problems as high team WIP: slow delivery, unpredictable timelines, and hidden problems. Product managers who limit concurrent initiatives enable faster, more predictable execution.
Signs of wip problems
Watch for indicators of excessive WIP:
These symptoms respond to WIP reduction even when the root causes seem different.
Getting started
Teams new to WIP management can start simply:
Tools like Klero support WIP-aware product development by helping teams understand which user needs are most urgent, enabling better decisions about what to work on - and what to defer - to maintain healthy WIP levels while maximizing customer value.
