Skip to content
← Tools & Resources

Free tool

Flow Efficiency Calculator

Take one recently completed item, for example a request, a change or 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.

  • 2 inputs
  • ~1 minute
  • Instant result
  • Free
First: which kind of days will you count?

The whole span, waiting included: from the moment it was requested to the moment the result arrived.

working days

Only hands-on time. Enter it in hours: 45 minutes on the form is 0.75, not 45.

hours
What counts as actual work?

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.

runs / year

Finding the problem is only half the job

How to fix it is what the “Getting results into operations” course covers: an application that takes six weeks is redesigned step by step. Or bring your own value stream and work on it in the exercises.

View the course →

Nothing you typed above is sent anywhere. The link simply opens the course page.

The calculation assumes one working day = 8 working hours. If you counted calendar days, they are converted to working days at 5÷7 before that (an approximation that ignores public holidays). Counting a full 24-hour day as waiting would look more dramatic and would be dishonest.

On benchmarks: the widely quoted “5 to 15 percent is typical” is practitioner lore from conference talks rather than the result of a study, and who said it first cannot be pinned down. The one large published measurement (63 teams over twelve months at ASOS, by Nick Brown) found 9 to 68 percent, averaging 35. There is no settled benchmark, which is why this page compares your process against itself rather than against a band.

Everything on this page is arithmetic on your own numbers. Nothing is sent unless you save the result to your account.

Calculating flow efficiency: formula, interpretation, limits

Flow efficiency compares actual working time with 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, so 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.

The two inputs

Lead time in days
From the trigger to the delivered result, in calendar days. Not from the moment someone started work, but from the moment the request existed.
Actual work in hours
Only the hours in which someone genuinely worked on the item. Being on call, being responsible, or having an open ticket does not count.

Frequently asked questions

How is flow efficiency defined?

Work time divided by lead time, as a percentage. Lead time starts when the request existed, not when work began — otherwise you leave the waiting out of your own calculation.

What is a good value?

There is no dependable answer. The widely quoted “5 to 15 percent is typical” is practitioner lore from conference talks rather than the result of a study, and who said it first cannot be pinned down. 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.

Is a low value bad?

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 you where to start looking.

Why does speeding up the work push the number down?

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.

Why does this matter in project management?

It gives you an argument. “We need more people” and “ninety percent of the time we are waiting for an approval” lead to entirely different actions — and only the second one can be backed by a measured number.

Further reading

Flow Efficiency Calculator — free — Agile Forge