Flow Efficiency: Are You Working or Waiting?

WHY IT EXISTS Teams often feel busy, yet work moves slowly through the system. Flow efficiency was created to quantify this feeling by separating value-add time (active work) from non-value-add time (waiting). It shifts the focus from individual productivity to the health of the overall delivery process.

THE MENTAL MODEL Think of a restaurant order. The chef might spend 10 minutes actually cooking your meal (active work). But the ticket might spend 5 minutes on the rail before being seen and another 15 minutes on the pass waiting for a server. The total lead time is 30 minutes, but the active work time was only 10. The flow efficiency is 10 divided by 30, or 33%. The system, not just the chef, is the source of delay.

HOW IT WORKS Calculate it with the formula: (Total Active Work Time / Total Lead Time) * 100%. To get these numbers, you track the time a work item spends in different states on your Kanban or Scrum board. States like 'In Progress' or 'In Review' are typically active. States like 'To Do', 'Ready for Review', or 'Blocked' are wait states. Sum the time spent in active states and divide by the total time from commitment to completion. For most software teams, a flow efficiency of 5-15% is common, which is often a shocking realization.

WHEN TO USE IT Use flow efficiency when your cycle times are long and unpredictable, but you don't know why. It is a powerful diagnostic for Kanban systems to identify and prioritize the removal of bottlenecks. It provides concrete data to justify process changes, such as reducing Work In Progress (WIP) limits, dedicating more time to code reviews, or automating testing environments.

WHEN NOT TO USE IT Do not use flow efficiency as a performance metric for individuals; it measures the system, not the person. It's also less useful for highly creative, non-repeatable R&D work where 'wait time' might actually be valuable 'thinking time.' Finally, chasing a perfect measurement is a form of waste; a good-enough estimate is usually sufficient to find the biggest delays.

ONE CANONICAL EXAMPLE A feature takes 10 working days to go from 'To Do' to 'Done'. The team analyzes its journey. Development took 2 days. It then waited 4 days in the 'Ready for Review' queue. The code review itself took 1 day. Addressing feedback took another day. It then waited 1 day for a QA environment. Testing and deployment took 1 final day. The total lead time was 10 days. The total active work time was 2 (dev) + 1 (review) + 1 (fixes) + 1 (test/deploy) = 5 days. The flow efficiency is (5 / 10) * 100% = 50%. The biggest opportunity is the 4 days spent waiting for review.