Pick a closed ticket from last month. Look at when it was opened and when it closed, then estimate how many of those hours anyone actually spent on it.
The ratio is usually shocking the first time. Nine calendar days, six hours of work. A fortnight, a day and a half. That ratio is flow efficiency, and the gap between the two numbers is where almost all of your lead time lives.
What the number means
Flow efficiency is active time divided by total elapsed time. A team at 25% is spending three quarters of every item's life with the work sitting still.
It is worth sitting with the implication, because it reorders priorities. If an item spends 75% of its life waiting, then every initiative aimed at making people work faster is competing for the smallest quarter of the problem. Better tooling, more focus, a faster test suite — all genuinely useful, all operating on the 25%.
The waiting is where the leverage is, and the waiting is structural. It is handoffs, review queues, blocked dependencies, waiting on a decision, waiting on another team, waiting for someone to come back from leave.
This is also why flow efficiency pairs well with DORA metrics rather than competing with them. DORA tells you lead time is nine days. Flow efficiency tells you that seven of them were queueing.
Where the waiting actually accumulates
Four queues account for most of it, and they are all measurable from your tracker.
Review. The single largest one in most engineering teams. A pull request that waits eleven hours for a first look has added a day and a half to its own lead time while consuming no effort from anyone. The developer experience lens treats this as a feedback-loop problem, which is the same finding from the other direction.
Handoffs between functions. Engineering to QA, design to engineering, anything that crosses a team boundary. Each boundary is a queue, and each queue has a wait time that scales with how busy the receiving side is.
Blocked on a decision. Frequently the longest individual waits, because there is no queue to watch and no owner. An item waiting on a product answer can sit for a week with nothing happening and nobody accountable.
Blocked on another team. Which in distributed organisations compounds with time zones — an eighteen-hour round trip on a clarifying question turns a two-minute answer into a two-day delay. The offshore and nearshore piece covers measuring this specifically.
Why starting less finishes more
The standard response to a backlog is to start more things. It reliably makes throughput worse, and the reason is queueing rather than motivation.
Every concurrent item does three things. It adds switching cost to the person holding it, so each item progresses more slowly — the cost of context switching quantifies that. It lengthens the queue at every downstream stage, so everything else waits longer. And it hides which item is actually blocked, because everyone has something to work on and nothing appears stuck.
WIP limits attack all three. Cap the number of items in progress and work has to finish before new work starts. Queues shorten, switching drops, and — the part people find uncomfortable — blockages become visible immediately, because when you cannot start something new you have to go and unblock what you have.
That visibility is the actual mechanism. A WIP limit does not make anyone work faster; it makes the system's problems impossible to route around.
Measuring it without a new tool
You almost certainly have the data. Issue trackers record state transitions, which is all you need.
Total elapsed time is close to close minus created. Active time is the sum of time spent in whichever states mean someone is working — typically "in progress" and "in review", though you should decide deliberately whether review counts as active, since waiting for review plainly is not.
The number will be approximate, because "in progress" does not guarantee anyone touched it. That is fine. If the honest answer is somewhere between 20% and 30%, you do not need two decimal places to know that the waiting is the problem.
What activity data adds, if you have it, is a sanity check on the active half: whether the time nominally spent in progress corresponds to anyone actually being in the relevant tools. A team whose tickets sit in "in progress" for days while nobody opens the codebase has a status-hygiene problem rather than a flow one, and those need different fixes.
The caution worth stating
Flow efficiency is a system metric and it degrades badly if applied to people.
A developer whose items have low flow efficiency is usually the one working on the most entangled problems, or the one whose work depends on the most other people. Scoring them on it penalises the hardest work in the team — and once anyone understands the metric affects their standing, items start being created later and closed earlier, which makes the number look better and tells you nothing. Productivity theatre is the general version of this.
Read it per workflow, per team, per stage. Never per person.
Where ProdView fits
Flow efficiency itself comes from your issue tracker, not from us, and any vendor claiming to derive it from desktop activity is overreaching. What ProdView adds is the other half: whether the people in the system have the uninterrupted time to do the active work at all, how fragmented their days are, how much of the week goes to coordination, and whether load is concentrated on a few people. Activity metadata only, aggregate-first, never screen content.
When not to pick us: your question is purely about queue times and state transitions. That is tracker data and you should go and get it from there — it is free and you already own it.
Try before you commit
Three seats are free forever. Compute flow efficiency from your tracker first, since it costs nothing, and only reach for activity data if the active quarter turns out to be where your problem is. The ROI calculator prices the waiting once you have measured it.