Most engineering squads are busier than ever, yet work still piles up in queues. Flow efficiency measures exactly how much of a work item's total cycle time is spent in active progress versus sitting idle. When flow efficiency is low, your squad isn't slow because players lack skill. They're slow because the process is full of wait states. This page covers the definition, formula, benchmarks, common mistakes, and how to start measuring flow efficiency on your team.
- Flow efficiency measures the percentage of total cycle time spent actively working on an item, rather than waiting in queues, blocked, or sitting in review backlogs. It reveals whether your delivery pipeline has a capacity problem or a flow problem, and it's one of the clearest signals of process health available to engineering leaders.
- Flow efficiency is calculated by dividing active time by total cycle time and multiplying by 100. No universally published benchmark exists from DORA, but lean manufacturing research and software delivery practitioners widely cite 15% as a typical baseline for knowledge work, with high-performing squads reaching 40% or above.
- The most common mistake teams make is treating flow efficiency as a measure of individual effort. A low score almost never means players aren't working hard enough. It means the process has too many handoffs, approval gates, or review queues creating wait time that no individual player can resolve alone.
- DevStats surfaces issue cycle time and PR cycle time data automatically by connecting to your Git provider and issue tracker, giving you the active vs. wait time breakdown you need to diagnose flow efficiency across your squads. Start a free trial to see your numbers in under two minutes.
Flow efficiency definition
Flow efficiency is the percentage of total cycle time during which a work item is actively being worked on. It answers a simple question: out of all the time a ticket or pull request spent in your system, how much of that time was someone actually working on it?
The formula is: Flow efficiency = (active time / total cycle time) × 100. Active time covers periods of genuine work, coding, reviewing, or testing. Total cycle time includes all time from when work started to when it was delivered, including wait states, blocked periods, and review queues. Teams that track issue cycle time alongside active time can calculate this ratio directly from their existing data. Low flow efficiency has a direct business consequence: longer delivery timelines, slower feedback loops, and reduced ability to respond to customer needs.
Why flow efficiency matters for engineering teams
Squads that don't track flow efficiency tend to misdiagnose their delivery problems. When a sprint slips, the instinct is often to add capacity or push for longer hours. But if flow efficiency is at 10%, adding more players won't help. The bottleneck isn't people. It's the time work spends waiting for review, waiting for sign-off, or sitting in a backlog between stages.
Flow efficiency connects directly to the KPIs most engineering leaders report upward: on-time delivery, sprint predictability, and release cadence. When wait time is invisible, it's impossible to address. Tracking PR cycle time is one of the fastest ways to surface where flow breaks down in your delivery process, since pull requests often accumulate the most visible wait time in a squad's workflow. Flow efficiency also maps cleanly to the Flow dimension of the SPACE framework, which treats uninterrupted, low-friction work as a core component of engineering productivity.
Measurement is the first step. The engineering leader is the one who decides what to change once the data is visible.
How to measure flow efficiency
To calculate flow efficiency, you need two data points for each work item: the total time from work start to delivery, and the time during which active work was happening. Most issue trackers record status transitions, which let you reconstruct both figures. Your Git provider adds precision by showing when commits and reviews were actually happening.
Flow efficiency benchmarks vary by team size, codebase maturity, and release model. No single published standard from DORA covers this metric directly. The table below reflects widely cited thresholds from lean software delivery research and practitioner benchmarks. You can compare your squad's numbers against peer teams using DevStats benchmarks.
| Performance level | Flow efficiency benchmark | What it signals |
|---|---|---|
| Elite | 40% or above | Minimal wait states; work moves through the system with few handoff delays |
| High | 25–39% | Some queue time present but process is generally well-managed |
| Medium | 15–24% | Typical for knowledge work; meaningful improvement opportunity exists |
| Low | Below 15% | Most cycle time is wait time; process bottlenecks are likely systemic |
Note: these thresholds are drawn from lean manufacturing and software delivery practitioner research, not a single authoritative benchmark report. Treat them as directional, not prescriptive.
Flow efficiency in practice: a real example
A VP of Engineering at a 40-person SaaS company noticed that sprint velocity looked healthy on paper, but features were consistently taking three to four weeks from ticket start to production. She pulled issue cycle time data and found that the average ticket spent 18 days in the system, but only 2.5 days of that involved active work. Flow efficiency was sitting at roughly 14%. The bottleneck wasn't coding. It was a review queue where PRs waited an average of four days before a second reviewer picked them up.
She introduced a squad-level norm: any open PR older than 24 hours gets flagged in the daily standup. Within two sprints, average PR review wait time dropped significantly, and issue cycle time fell from 18 days to under 11. She tracked the change using PR cycle time data week over week, which gave her an objective signal that the process change was holding, not just a one-sprint anomaly.
How to improve flow efficiency
- Map your wait states before changing anything. Pull status transition data from your issue tracker and identify where work sits longest. Blocked states, review queues, and "ready for QA" columns are common culprits. You can't reduce wait time you haven't measured. DevStats's issue cycle time view breaks down time-in-stage so you can pinpoint the exact stage causing drag.
- Set explicit review SLAs for pull requests. If PRs routinely sit for more than 24 hours, code review wait time is compounding your flow problem. Set a squad norm for first-review turnaround and track it weekly. Watch code review metrics as a leading indicator. When review turnaround improves, flow efficiency tends to follow within one to two sprints.
- Reduce work-in-progress limits. High WIP is the structural cause of most flow problems. When players are context-switching across five tickets simultaneously, each ticket moves slowly. Cap WIP at the squad level and measure whether active time per ticket increases. Watch throughput alongside flow efficiency. Improved flow efficiency should increase throughput without adding headcount.
- Audit your approval and deployment gates. Manual approval steps before deployment are a common source of invisible wait time. Review your deploy pipeline for gates that could be automated or batched less frequently, and measure whether removing them changes your cycle time distribution.
- Review sprint planning for overcommitment. Squads that consistently overcommit create their own wait states as work queues behind bottlenecked players. Use planning accuracy data to right-size sprint scope, which reduces the internal queuing that drives flow efficiency down.
Flow efficiency vs. cycle time
Flow efficiency and cycle time are related but measure different things. Cycle time measures how long work takes from start to finish. Flow efficiency measures how much of that time was actually productive.
| Flow efficiency | Cycle time | |
|---|---|---|
| Measures | Ratio of active work time to total elapsed time | Total elapsed time from work start to delivery |
| Starts when | Work item enters active state | Work item is picked up or started |
| Ends when | Work item is delivered | Work item is delivered |
| Best for | Diagnosing process waste and wait states | Forecasting delivery timelines and sprint commitments |
Use cycle time when you need to predict delivery. Use flow efficiency when you need to understand why delivery is slow. The two metrics work together: a short cycle time with low flow efficiency means work is moving fast but could move faster still.