Deploy free

Work in progress: the number that makes the case for WIP limits

The WIP widget shows one thing: how many issues are open and being worked right now, plus an 8-week sparkline of how that count moved. It's the simplest case for WIP limits you'll ever see — more items in flight, almost mechanically, means longer cycle time for every one of them.

deckgauge · Board · Intelligence
Work in progress
18
items in progress

Current WIP with an 8-week trend.

What it measures, and where the data comes from

One count, sourced from whatever issue trackers your board is connected to: Jira, Azure DevOps, and GitHub issues. An item counts once it's started and until it's done — the sparkline is just that count, snapshotted weekly for eight weeks.

  • Jira — issues whose status maps to an in-progress category on your synced boards. Anything still sitting in a To Do column, or already Done, doesn't count.
  • Azure DevOps — work items in an in-progress state per your Boards column mapping. Same idea, ADO's vocabulary.
  • GitHub — open, assigned issues. GitHub has no native "in progress" state, so this is the roughest of the three proxies — a repo where issues sit open and unassigned for weeks will understate real WIP, and one where people assign themselves the moment they glance at something will overstate it.
Mixed sources, one numberIf a board pulls from more than one tracker, the count is a simple sum. Skewed hygiene in one source (stale GitHub assignees, say) will quietly distort the total — check the mix before you act on a surprising jump.

How to read it

Don't stare at the number in isolation — compare it to team size. A team of eight comfortably holding ten to sixteen items is normal; the same team holding thirty is not, no matter how the sparkline looks. This is Little's Law showing up on your dashboard, plainly: average cycle time works out to roughly WIP divided by how fast items complete. Your completion rate doesn't change much week to week, so every extra item in flight adds directly to how long everything takes.

Then look at the shape of the sparkline, not just today's dot. Flat and low is healthy. A slow, steady climb over several weeks is the leak — it means the team is starting faster than it's finishing, and cycle time is about to catch up with everyone.

What it tells you over time

A single high reading is a snapshot; a rising trend is the real signal. One busy week where WIP ticks up is normal — sprint planning does that. Eight weeks of steady climb, with no matching climb in throughput, means the backlog of "started" work is quietly growing, and it will show up as slower delivery a month from now if nobody touches it.

Example situations

1. The sparkline keeps climbing

deckgauge · WIP
Work in progress
24
items in progress — up from 14 eight weeks ago

WIP trending up for two months straight.

What you're seeing: a clean, steady climb with no plateau. The team keeps saying yes to new work without closing out the old — nobody decided this, it just accumulated one "quick, start this too" at a time.

How to react: resist the instinct to tell people to "wrap things up faster." The fix isn't speed, it's arrival rate — fewer things starting, not the same things finishing quicker. Cross-check against Velocity with Confidence and Lead Time for Changes: if completions are flat while WIP climbs, this is exactly the pattern, not a coincidence.

Managerial playPut an explicit WIP limit on the board — a hard column cap the team enforces, not a suggestion. "Finish before you start" becomes the default: nobody picks up new work while the limit is full. In standup, ask what got closed yesterday before asking what's in flight, and make closing visible in the same way starting always was.

2. WIP is way beyond what the team can hold

deckgauge · WIP
Work in progress
27
items in progress — team is 8 engineers

27 items in flight on an 8-engineer team.

What you're seeing: the count isn't climbing so much as it's stuck high — roughly three-plus items per engineer, every week, for two months. That's not a backlog problem, it's a focus problem: everyone is juggling several things at once instead of finishing any one of them.

How to react: a number this far above team size is a context-switching tax, and it's invisible on any individual's calendar — nobody feels "busy" doing it, they just feel behind on everything. It rarely resolves by adding people; it resolves by subtracting concurrent work.

Managerial playCall a swarm: pick the two or three oldest in-progress items and get pairs or trios finishing them this week before touching anything new. Protect focus deliberately — no new assignments mid-sprint without something closing first. Say out loud that "started" isn't progress; "done" is the only thing that counts toward the number that matters.

Frequently asked

What does the work in progress widget measure?
How many issues are open and actively being worked right now, plus an eight-week sparkline showing how that count has moved.
Why do WIP limits shorten cycle time?
Because more items in flight means each one waits longer for attention. The relationship is close to mechanical: holding throughput steady, cycle time rises roughly in proportion to work in progress.
What should I do when the WIP sparkline climbs?
Finish before starting. A rising WIP count almost always precedes a rise in cycle time, so it is the earliest actionable warning on the dashboard.

Related widgets

Last updated