Free tool
Take one recently completed item — a request, a change, an approval. Count the days from the trigger to the delivered result. Then estimate the hours of actual work inside it. This page puts the two numbers next to each other.
The whole span, waiting included: from the moment it was requested to the moment the result arrived.
Only hands-on time. Enter it in hours: 45 minutes on the form is 0.75, not 45.
Lean distinguishes three kinds of time: value-adding work, necessary non-value-adding work (for example a legally required check), and waste. For this calculator, count the first two — every minute the item is actively being processed, including reviews and approvals while they are actually being done. Do not count the time the item spends sitting: mailboxes, ticket queues, batch windows, waiting for a meeting or a release slot.
Several people at once. Count the elapsed hands-on time once, not the sum per head. A one-hour meeting with four people is one hour here, not four. Person-hours would inflate the work side and can exceed the lead time altogether.
Machines doing the work. If the item is actually being transformed — a pipeline building it, an overnight job processing it — that is processing time, not waiting, even though nobody is touching it. Time it merely sits in a queue is waiting, machine involved or not. Either way: decide once and apply the same rule to every item, or your numbers won't be comparable.
Solving it is what the course is about. In DevOps and IT Service Management, we revisit the same six-week example and redesign it step by step. Or bring your own value stream, and we’ll improve it together.
Look at the course →Nothing you typed above is sent anywhere — the link simply opens the course page.
Flow efficiency puts actual working time against total lead time: work time divided by lead time, times one hundred. If an item takes twenty days and contains sixteen hours of work, that is two working days at eight hours each — ten percent.
The number is interesting because it inverts the usual view. People who want to cut lead time normally speed up the work. At ten percent flow efficiency, though, ninety percent of the time is waiting — that is where the leverage sits, and that is where hardly anyone looks.
Work time divided by lead time, as a percentage. Lead time starts when the request existed, not when work began — otherwise you measure the waiting out of your own calculation.
There is no dependable answer. The widely quoted “5 to 15 percent is typical” is practitioner lore traceable to talks by David J. Anderson rather than to a study. The one large published measurement — 63 teams at ASOS — found 9 to 68 percent. The useful comparison is your own process at an earlier point in time.
Not necessarily. A low value means a lot of time sits in waiting — that can come from dependencies, approvals or prioritisation, and it is sometimes a deliberate choice. The number judges nothing; it shows where it would be worth looking at all.
Because the numerator shrinks — at the same lead time, flow efficiency falls when the work gets faster. That is exactly the point: use the number as a target and you end up optimising in the wrong direction. It is a diagnosis, not a reporting metric.
As an argument. “We need more people” and “ninety percent of the time we are waiting for an approval” lead to entirely different measures — and only the second one can be backed by a measured number.