• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Work in Progress (WIP) per Team or Stream

Description

Work in Progress (WIP) refers to the number of items a team is actively working on at any given time. High WIP levels are often linked to delays, context switching, and reduced flow efficiency. Monitoring WIP per team or value stream helps improve focus, reduce multitasking, and increase delivery predictability.

By actively managing WIP, teams are better able to finish what they start, deliver smaller increments more frequently, and optimise the flow of work through the system.

How to Use

What to Measure

  • Count the number of items in “in progress” states across a given workflow (e.g. development, testing, review).
  • Measure WIP for each team, stream, or swimlane.
  • Optionally break down by item type (e.g. story, bug, spike).

Measure:

  • Average WIP per sprint or week
  • Maximum concurrent WIP
  • Distribution of WIP across workflow stages

Formula

WIP = Number of Items in Active States at a Given Time

You may track this as a point-in-time snapshot or as a trend over time using rolling averages.

Instrumentation Tips

  • Use visual boards (Jira, Azure DevOps, Trello) to monitor active columns.
  • Implement WIP limits on key workflow stages to guide team behaviour.
  • Use dashboards or burn-up charts to show WIP trends and variations.

Benchmarks

There are no universal WIP targets, but guidance includes:

Team Size Suggested Max WIP (Total)
3–5 3–6
6–8 5–8
9–12 7–10

WIP should be proportional to team capacity, work item size, and available focus. Use empirical observation to define sustainable WIP levels.

Why It Matters

  • Improves flow and focus
    Lower WIP allows teams to concentrate on fewer things, reducing context switching and rework.

  • Increases throughput
    Managing WIP is strongly correlated with shorter cycle times and higher delivery rates.

  • Reduces risk
    Lower WIP levels reduce the cognitive load and surface issues earlier.

  • Enables better forecasting
    Stable WIP supports more reliable delivery planning and predictability.

Best Practices

  • Set team-defined WIP limits per stage or person.
  • Visualise WIP clearly in team ceremonies and on boards.
  • Review WIP in stand-ups and retros to detect overload or neglect.
  • Encourage a culture of finishing over starting.
  • Combine with Work Item Age to detect flow risks early.

Common Pitfalls

  • Allowing WIP to grow without review, leading to delayed or forgotten work.
  • Setting WIP limits but not enforcing or revisiting them.
  • Counting paused or blocked work as inactive (inflating available capacity).
  • Misinterpreting high WIP as productivity rather than potential risk.

Signals of Success

  • WIP trends are stable and aligned to team capacity.
  • Teams prioritise finishing existing work before starting new.
  • Cycle time and throughput improve as WIP stabilises.
  • Teams engage in proactive WIP limit setting and adjustment based on evidence.

Related Measures

  • [[Cycle Time per Work Item Type]]
  • [[Work Item Age]]
  • [[Flow Efficiency]]
  • [[Throughput Rate (Items Completed per Sprint or Week)]]

Aligned Industry Research

  • Kanban Method (David J. Anderson)
    Limiting WIP is a foundational principle that enables flow, reduces delay, and increases predictability.

  • ActionableAgile (Daniel Vacanti)
    Shows that WIP is a key lever in balancing capacity and demand.

  • Lean Thinking (Womack & Jones)
    Advocates reducing excess work-in-process as a way to eliminate waste and improve system efficiency.

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering