Flow efficiency is the share of an item's cycle time spent being worked on: add up the days it sat in active states, divide by its whole cycle time, and you have it. You need each item's state history to do this, because the current state only says where an item is now, not how long it spent in each state on the way.
The formula
Flow efficiency = touch time / cycle time.
- Touch time is the days an item spent in active states, where someone is working on it: In Progress, Test, Review.
- Wait time is the days it spent in queues: ready for test, waiting for review, waiting for approval.
- Cycle time is touch time plus wait time, from the first time the item entered an in-progress state to the moment it reached Done.
A worked example
A story spends 2 days in development, 4 days ready for test, 1 day in test and 3 days waiting for release approval. Touch time is 3 days, wait time is 7, cycle time is 10. Flow efficiency is 3 / 10 = 30%. For a team figure, divide the total touch time by the total cycle time across the finished items, so a handful of very short items does not distort the result.
Why you need state history, not the current state
A work item query returns each item as it is at one moment. That is enough to count what is in progress today, but it cannot tell you that an item spent four days in a queue last week. That lives in the item's revisions: every state change records the old state, the new state and when it happened.
- Read each finished item's updates, through the REST API (work item updates) or the revision history in the Analytics service.
- Keep only the changes to
System.Stateand sort them by date. - For each state, take the time from entering it to leaving it. Add up repeat visits: an item that bounces between Test and Active counts both visits.
- Start the clock at the first in-progress entry and stop it at Done.
Map every state to active or waiting
The number is only as good as the mapping behind it. The Azure DevOps state categories do not separate "being worked on" from "waiting": a ready-for-test column and a testing column can both sit under In Progress. Go through every state on your board and put it in one group.
- Active: someone is doing the work now (development, test, code review).
- Waiting: the item is ready but nobody is on it (ready for dev, ready for test, awaiting approval, blocked).
- Done: the first state where the work counts as finished.
Related: Azure DevOps state categories
How to read the result
Read flow efficiency as a range, not a target to push up.
- Under 15%: most of the cycle is waiting. Look at handoffs, review queues and approvals before asking anyone to work faster.
- 15% to 40%: the healthy band for most knowledge-work teams, from Daniel Vacanti's benchmarks.
- Above 40%: better than typical. Still check that no waiting state is mapped as active.
- 95% or more: almost always a data problem, not a great team. Usually waiting states are mapped as active, or the board has no queue columns at all.
Then find where the waiting is
A single large queue is easier to fix than a general low number, so look at which states hold the waiting time. Check the slowest items one by one as well: one item stuck for weeks can hide inside a team figure.
Doing it in Agile Analytics
The Flow Efficiency view, in the Measure group, does the whole calculation in your browser against the Azure DevOps REST API, with no Power BI and no personal access token. It states the rule on screen: "Flow efficiency = touch time / cycle time." Touch time counts states mapped to In Progress, Test or Review, and wait time counts states mapped to Queued, set in Configuration → Workflow Mapping.
- Sprints: 3, 6 or 12 sprints of finished work (6 by default).
- Touch time, Wait time and Total cycle cards, and a Touch vs wait bar split into Active work and Waiting.
- Where the time goes: the days spent in each state across the finished items, grouped under Active work and Waiting / queues. This answers "how long do items spend in each state?"
- Items by cycle time (longest first), each with Open in ADO.
- A verdict against the healthy 15 to 40% band: Below healthy, Healthy, Better than typical (above 40%), or Suspicious when it reaches 95%.
- Left out: how many items had no usable state history or were not finished yet.
- A CSV export with one row per finished item: item_id, type, cycle_days, touch_days, wait_days and efficiency_pct.
Related: Flow metrics for Azure DevOps
Try it
Agile Analytics runs on Azure DevOps Services (cloud). The 30-day free trial starts on install with no credit card, and every plan includes the Flow Efficiency view. Check your Workflow Mapping first, then open Flow Efficiency and look at Where the time goes. The extension is on the Azure DevOps Marketplace.
Related: Workflow Mapping docs · Install instructions