Skip to main content
Version: 2.0

Work In Progress (WIP)

For 20+ years, I’ve seen engineering teams – from scrappy startups to established giants – fall victim to the same insidious problem: too much Work In Progress (WIP). It’s not a flashy failure; it doesn’t usually cause immediate fires. Instead, it’s a slow, creeping drain on productivity, a quiet killer of throughput, and a major source of frustration for everyone involved.

Imagine a team constantly context-switching between features, chasing the latest urgent request while existing work languishes. Sound familiar? As engineering managers, we're often focused on starting things – kicking off new features, accepting ambitious projects. But we often prioritize starting new work over finishing what’s begun. And that, my friends, is where ruthless WIP management comes in.

The Hidden Costs of a Full Plate​

Think about it: you have a developer working on Feature A. Halfway through, they get pulled onto a critical bug for Feature B. Then a “quick” UI tweak for Feature C pops up. Suddenly, they're context-switching constantly, losing valuable focus and incurring a significant cognitive load. This isn’t just about time lost; it's about lost momentum.

Each new task added to the pile introduces:

  • Increased Context Switching: The brain isn't a great multi-tasker. Constant switching significantly reduces efficiency. Studies on cognitive load and task switching demonstrate a significant performance decrease when individuals are forced to juggle multiple priorities.
  • Hidden Costs of Re-engagement: It takes time to re-immerse yourself in a problem after being interrupted. You lose train of thought, have to re-examine code, and potentially rediscover solutions.
  • Delayed Feedback: When things are perpetually "in progress," you don’t get valuable feedback from testing, users, or stakeholders, hindering learning and improvement.
  • Increased Risk: Half-finished features are a breeding ground for technical debt and integration nightmares.

Beyond Kanban: Understanding the Core Principle​

Many teams jump to Kanban as a solution, and it can be helpful. But Kanban is a tool, not a magic bullet. The core principle driving WIP limits isn’t just about visualizing work on a board; it’s about constraining the amount of work in progress to force focus and accelerate completion.

Think of it like a production line in a factory. If you overload the line with too many parts in process, everything slows down. Adding more parts (more WIP) doesn’t magically make things faster. In fact, it creates congestion and bottlenecks.

Practical Strategies for Managing WIP​

So, how do you implement this in your team? Here’s what I’ve found works best:

  1. Visualize Your Workflow: Use a Kanban board (physical or digital) to map out your team’s workflow – from “To Do” to “In Progress” to “Done.” This transparency is crucial.

  2. Establish WIP Limits: This is the hard part. Based on your team size and complexity of work, set strict limits on the number of items allowed in each stage of the workflow. Start conservatively. A good rule of thumb is to limit “In Progress” to roughly the number of developers actively working on features.

  3. “Stop Starting, Start Finishing”: Make this a mantra. Before accepting a new task, ask: “What needs to be completed or blocked before we can start this?” Prioritize finishing what's already in progress.

  4. Prioritize ruthlessly: Not everything is equally important. Use a framework like RICE (Reach, Impact, Confidence, Effort) – a scoring system that helps evaluate potential projects – or MoSCoW (Must have, Should have, Could have, Won’t have) – a categorization technique for prioritizing requirements – to prioritize relentlessly. Don't be afraid to say "no" or defer less critical items.

  5. Swarming: When a critical item gets blocked, swarm on it. Bring multiple team members together to focus their combined expertise on resolving the issue quickly. This is far more effective than individual developers spinning their wheels. Swarming is most effective for unblocked blockers – problems where the team can immediately collaborate.

  6. Regular Check-Ins: During daily stand-ups, focus not just on what people were working on but also on what they finished and what's blocking them.

Dealing with Resistance​

Implementing WIP limits will likely face some resistance.

  • “But I’m bored!” Address this by ensuring people have challenging and impactful tasks available within the WIP limits. Encourage them to contribute to testing, code review, or documentation as valuable ways to stay engaged.
  • “We need to start this now!” Push back. Explain the benefits of finishing existing work. Negotiate a realistic timeline for starting the new item.
  • “It’s slowing us down!” This is often a short-term effect. Explain that reducing context switching will ultimately increase velocity. Monitor throughput and demonstrate the improvement.

The Long Game​

Managing WIP isn't a one-time fix; it's a continuous process of refinement and adaptation. By consistently focusing on finishing work and limiting the amount in progress, you’ll not only improve your team's throughput but also foster a culture of focus, predictability, and quality.

Start by visualizing your current workflow and identifying bottlenecks. Then, experiment with WIP limits in a small pilot project.