Flow metrics

Most engineering leaders can tell you how many story points their squad completed last sprint. Far fewer can tell you where work actually got stuck. Flow metrics give you that visibility: they measure how work moves through your delivery system, from the moment an idea is picked up to the moment it ships. This page covers the definition, how to measure each flow metric, benchmarks, a real example, and how DevStats surfaces this data automatically.

• Flow metrics are a set of four measurements (flow velocity, flow time, flow efficiency, and flow load) that describe how work moves through a software delivery system. They shift the focus from individual output to system-level performance, which is where most delivery problems actually live.
• Flow metrics are calculated from issue and work item data across your delivery pipeline. There are no universally published benchmarks for all four metrics, but flow efficiency below 15% and flow time above 30 days are widely considered signals of systemic bottlenecks. Benchmarks vary by team size and release model.
• The most common mistake teams make with flow metrics is measuring flow velocity in isolation. A squad shipping more items per sprint while flow time climbs and flow efficiency drops is not improving. Velocity without the other three metrics is misleading and can mask growing dysfunction in your delivery system.
• DevStats surfaces throughput, issue cycle time, and related flow signals automatically by connecting to your Git provider and issue tracker, with benchmarks against 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.

Flow metrics definition

Flow metrics are a set of four measurements that describe how efficiently work moves through a software delivery system: flow velocity (how many items ship per unit of time), flow time (how long each item takes from start to done), flow efficiency (the ratio of active work time to total elapsed time), and flow load (the number of items in progress at once). Together, they give you a systems-level view of your delivery process.

The framework was popularized by Mik Kersten in Project to Product and is grounded in lean manufacturing principles applied to software. Flow efficiency is calculated as: Flow Efficiency = Active Time / (Active Time + Wait Time). When flow load is high and flow efficiency is low, you have a congestion problem, not a capacity problem. Improving flow metrics directly correlates with faster time-to-market and more predictable delivery commitments to stakeholders.

Teams that want to connect flow metrics to their broader measurement framework can pair them with DORA metrics, which measure deployment frequency, lead time for changes, change failure rate, and mean time to restore. The two frameworks are complementary: DORA measures delivery pipeline health, while flow metrics measure the upstream work management system.

Why flow metrics matter for engineering teams

When squads do not track flow metrics, bottlenecks become invisible. Work piles up in review, in staging, or waiting on a dependency, and the only signal leadership gets is a missed sprint. By the time the sprint retrospective surfaces the issue, the delay has already compounded across multiple work items and the team is already behind on the next cycle.

Flow metrics connect directly to the KPIs engineering leaders are accountable for. Predictable delivery improves stakeholder trust. Lower flow time shortens feedback loops with customers. Healthy flow efficiency signals that your squad is spending time building, not waiting. And tracking flow load helps you catch work-in-progress creep before it turns into burnout. You can see throughput trends alongside cycle time data to understand whether your squad is delivering more items or simply starting more items without finishing them.

Flow metrics align with the SPACE framework's emphasis on measuring systems and processes rather than individual output. Measurement is the starting point. The engineering leader is the one who reads the data, applies context, and decides what to change.

How to measure flow metrics

Flow metrics are calculated from work item data in your issue tracker, typically Jira, Linear, or GitHub Issues, combined with timestamps from your Git provider and CI/CD pipeline. You need start timestamps (when work was picked up), end timestamps (when it shipped), and state transition logs (to calculate active versus wait time). Without state transition data, you can calculate flow time and flow velocity, but not flow efficiency.

No single published benchmark covers all four flow metrics the way DORA's State of DevOps report covers deployment frequency and lead time. The table below reflects qualitative ranges widely cited by practitioners and Lean software delivery researchers. Benchmarks vary by team size, codebase complexity, and release model. DevStats's benchmarks feature lets you compare your flow signals against teams with similar profiles.

Note that these ranges are qualitative guides, not absolute thresholds. A squad shipping large, complex features will naturally have longer flow times than one shipping small, incremental changes. Context always matters when interpreting the numbers.

Flow metrics in practice: a real example

A VP of Engineering at a 45-person SaaS company noticed that sprint velocity looked stable but the team kept missing release dates. She pulled flow time data across the last three months and found that the median flow time for backend work items had climbed from 9 days to 22 days. Flow efficiency had dropped to 18%. The data pointed to a specific pattern: items were sitting in code review for an average of 6 days before getting a first response. She was not looking at who was slow to review. She was looking at a process gap.

She introduced a squad agreement: all open PRs get a first review within one business day. She also capped work in progress at three items per player. Over the next six weeks, she tracked PR cycle time and flow time together. Median flow time dropped to 13 days. Flow efficiency climbed back to 31%. The release date misses stopped. The intervention was hers. The data told her where to look.

How to improve flow metrics

1. Set a WIP limit per player and enforce it. High flow load is the single most reliable predictor of poor flow efficiency. When players are juggling four or five items simultaneously, context-switching inflates wait time across all of them. Start with a limit of two to three active items per player and adjust based on item size. Watch flow load weekly, not just at sprint end.
2. Audit your wait states, not your active work. Most flow time is lost in transitions: waiting for review, waiting for QA, waiting for a dependency team. Map every state in your issue tracker and calculate average time spent in each. The longest wait state is your first target. This is a process audit, not a performance review.
3. Reduce code review queue time with explicit SLAs. Review wait time is the most common flow bottleneck in squads over 10 players. A squad agreement that all PRs receive a first review within 24 hours consistently reduces flow time without requiring additional headcount.
4. Break large items into smaller, shippable units. Items that take more than five days to complete inflate flow time averages and make flow efficiency harder to improve. Work with your squad to define a maximum item size before sprint planning. Smaller items also improve planning accuracy, which compounds over time.
5. Review flow metrics at the squad level in weekly syncs, not just retrospectives. Flow time and flow efficiency are lagging indicators, but reviewing them weekly gives you enough signal to course-correct within the same sprint. DevStats surfaces these signals automatically so you spend the meeting discussing interventions, not pulling data.

Flow metrics vs. DORA metrics

Flow metrics and DORA metrics are often mentioned together, but they measure different layers of the engineering system. DORA metrics focus on the deployment pipeline: how often you deploy, how long changes take to reach production, how often deployments fail, and how quickly you recover. Flow metrics focus on the work management system: how items move from backlog to done, where they wait, and how efficiently the squad is operating upstream of deployment.

Use flow metrics to diagnose upstream delivery problems and DORA metrics to assess pipeline and reliability health. The two frameworks together give you a complete picture of your engineering system.