Flow Efficiency

When work ran late, the first question was who had done less of it, so companies measured how continuously people worked. A developer who filled eight hours a day with tasks looked healthy, and any gap in the calendar got another task dropped into it.

Yet teams where everyone was busy still took two months to ship one feature. "We're all here until late and nothing comes out" showed up every quarter. Nobody was idle, but the work was standing still. The spec waited for design to pick it up, the mockup waited for engineering, and finished code waited for code review. While each item waited, the person responsible was holding something else, so no individual record showed a gap.

Flow efficiency exposes that dead time by moving the subject of the measurement from the person to the work item. Instead of "how many hours did you work this week," it asks "of the 12 days this feature took, how many were spent touching it." Change the question and the waiting nobody considers theirs turns into a number.

Divide the time actually spent working on the item by the total elapsed time, then multiply by 100. A feature that shipped in 12 days with 3 days of hands on it has a flow efficiency of 25 percent.

Elapsed time is measured on the calendar, from the moment the item enters the queue to the moment a customer can use it, weekends and holidays included; this figure is called lead time. Strip out the waiting before anyone starts, measuring from the moment work actually began, and you have cycle time. Decide which one is the denominator up front, or the same item yields two figures more than twice apart.

Measuring takes three steps.

1. Pick one item and record its start and end times. The moment the ticket opened and the moment it closed will do.
2. Split the span into segments and mark each one as work or wait. Time when someone actively had their hands on the item counts as work; time when it sat in a queue for the next person's turn counts as wait.
3. Add up the segments marked as work and divide that sum by the total span.

Step 2 is where teams stall, since few of them log times to the minute. Start with nothing but the status-change history in the ticket tool: count time in the "in progress" column as work and time in "waiting for review" or "waiting for release" as wait, and a rough figure comes out. Knowing whether waiting is more than half of the span comes before getting the decimals right.

One item alone is at the mercy of its own circumstances, so take the last ten finished items, compute each, and use the middle value.

Teams measuring for the first time usually land between 5 and 15 percent. Three weeks of elapsed time with two days of actual work, and the team seeing that for the first time assumes someone made a mistake in the arithmetic. It isn't wrong and it isn't the mark of an unusually bad team; it's what most teams get on the first measurement.

Teams that keep working at it reach somewhere around 40 percent. A hundred percent isn't the goal. For an item never to wait, every reviewer would have to be sitting free whenever a request arrives, which just trades the item's waiting for people's waiting.

Low numbers almost always come from the wait segments. There's one reviewer and the queue stops whenever she's in a meeting, or one person holds five items at once so nothing finishes, or the approval step only opens every other day. That's why the lever for this number is the work in progress (WIP) limit, a cap on how many items may be underway at once. Opening two items instead of starting five means started work finishes sooner and the queue behind it gets shorter.

The direction answers more than the value. Fifteen percent becoming 20 means some wait genuinely shrank; sitting at the same place means last quarter's improvements never reached the flow. Don't use it to compare teams — where the segments get cut and what counts as waiting differ from team to team.

"Flow efficiency was 12 percent this quarter. We're not short on working hours, we're long on waiting."

A proposal to fix the wait segments rather than a request for more headcount.

"This card has an 18-day lead time and two days of real work. Let's find where the other 16 went."

Using one item as a sample to locate where things stopped.

"If raising flow efficiency means making everyone busier, it'll go down instead."

A warning that the more each person holds, the longer each item waits.

At Pagedeck, Mia brings this number to the quarterly retrospective. Pulling the last ten shipped features gave a middle value of 14 percent. When Theo split the spans apart, more than half the stopped time was waiting for code review. Only two people could review, and one of them was always in a meeting.

So the next quarter they widened the reviewer pool to four and agreed that a review request older than a day goes up as a blocker — an item stuck behind some other condition, and the list the team reads first every morning. A quarter later the figure was 22 percent, with the same number of people working the same hours.

The most common reading is that a low flow efficiency means the team is idle. The word efficiency makes it sound like a measure of how hard people work. But the subject of this value is one work item, not a person. Twelve percent means the item spent 88 percent of its time queued, and during that time its owner was holding other items. Act on the misreading and you pile more work onto people who are already full; the queue lengthens and next quarter's figure drops to 8 percent.

Drawing a value stream and then measuring once is the other one. A value stream is a picture laying out every segment a request passes through on its way to customer value, and writing flow efficiency onto it makes for a convincing slide. Stop there and all you have is a nice picture and one number. This value only moves when you measure the same way repeatedly and clear bottlenecks one at a time — the bottleneck being the slowest segment, the one that sets the pace of the whole flow, and clearing one usually promotes the next segment into the new bottleneck.