Work in Progress (WIP)

What it measures

Work in Progress measures the volume of work the team has opened but not closed at a given moment. In practice this is the set of in-flight items: feature branches with commits but no merge, pull requests still open for review, and tickets sitting in a doing or in-review state. It is a snapshot of concurrent load, not a rate.

WIP is a leading indicator of flow. When WIP climbs faster than throughput, work is piling up between stages and people are starting more than they finish. Low and stable WIP usually correlates with shorter cycle times because each item gets attention instead of waiting behind a queue.

How to measure it

Compute WIP from the artifacts your tools already produce. From git and the review system, count branches with unmerged commits ahead of the default branch and pull requests in an open or in-review state at a point in time. From the tracker, count tickets in active or review columns. Sample this daily so you can see the trend, not just one reading.

For a sharper picture, segment WIP by stage: coding (open branch, no PR), in review (PR open, awaiting approval), and ready to merge (approved, not yet merged). The stage where items accumulate tells you where the constraint is. Review-stage pileups point to reviewer capacity. Ready-to-merge pileups point to deploy friction or batching.

Pair WIP with cycle time and throughput to interpret it. WIP divided by throughput approximates average cycle time, which is the practical link between how much you carry and how long things take. Rising WIP with flat throughput is the signal to watch.

What it does not tell you

WIP tells you how much work is open, not whether any of it should be open. A team can hold low, tidy WIP while every item in flight advances a feature no customer asked for, and another can carry high WIP precisely because it is doing the hard, valuable work of a major migration. The count says nothing about which is which.

It also flattens importance. A trivial copy fix and a critical security patch each count as one unit of WIP, so the metric treats motion as uniform when it is not. It cannot tell you whether in-flight work maps to a committed initiative, whether two engineers are duplicating effort, or whether a stalled branch is blocked or simply abandoned.

This is the gap between measuring motion and measuring direction. WIP captures how much is in flight and, paired with cycle time, how fast it clears. It does not capture what is being built or why it matters. Execution Intelligence reads the content of the work and ties it back to strategy and cost, so a WIP number becomes a statement about which initiatives are actually in progress, not just how many tabs are open.

How InteliG uses it

InteliG derives WIP directly from real git and deployment history, so there is no manual instrumentation and no board to keep tidy. It reads open branches, unmerged pull requests, and unshipped commits as they exist in the source of truth, then resolves contributors from their actual commit and review activity.

From there Cognis connects each in-flight item to the initiative it belongs to, the people carrying it, and the cost it is accruing. The result is not a raw count but a reading of which strategic work is genuinely in progress, who is on it, and what it is costing while it stays open, so leaders can see whether their concurrent load is aimed at what matters.

Related terms

• Cycle Time — Time from first commit to merged or deployed for a unit of work
• Flow Efficiency — Share of cycle time spent in active work versus waiting in queues
• Execution Intelligence — Reading how an organization actually executes, from strategy through code to cost and outcome