Advanced Flow Analytics

By now you can set WIP limits, read a CFD, and write explicit policies. This unit goes one layer deeper: it gives you the math to explain why delivery feels slow and to forecast honestly. Start with the metric that reframes everything. Flow efficiency is the share of an item's lead time spent actually being worked on: touch time divided by the sum of touch time and wait time. Pull your last ten completed items, estimate how many days each was genuinely in progress versus parked in a queue, and the number usually lands somewhere between 5 and 25 percent. That single figure tells leadership the truth: the work isn't slow, the waiting is.

• Dan: Leadership thinks the team is slow, but I watched these cards. The actual work took maybe two days each.
• Nova: So where did the other twelve days go?
• Dan: Sitting. Waiting for review, waiting for a test environment, waiting on a dependency.
• Nova: That's your flow efficiency. Two touch days out of fourteen is about fourteen percent. Telling people to code faster fixes the two, not the twelve.
• Dan: So the leverage is the waiting, not the working.

Notice the move: once you express delay as a percentage, "work harder" stops being a credible answer and the conversation shifts to attacking queues and handoffs.

Wait time isn't one thing, so don't treat it as one. Carve out blocked time first: the hours an item sat with someone actively unable to progress it, waiting on an external answer, an environment, or another team. Track it with a timestamped blocker tag, because blocked time is the wait you can attack most directly, and its top causes repeat.

The rest of the waiting usually traces to variability, which comes in two flavors that need opposite fixes. Arrival variability is bursty, lumpy demand: five tickets land Monday, nothing Thursday. You smooth it with intake discipline, a buffer column, and firm WIP limits that stop the surge from flooding the board. Service variability is inconsistent work itself: one item takes a day, the next takes two weeks. You tame it by splitting large items, shrinking batch size, and standardizing the repeatable steps. The diagnostic habit is simple: before you intervene, ask whether the pain is coming in (arrival) or happening inside (service), because matching the wrong fix to the pattern just moves the queue somewhere else.

When someone insists the cure for slow delivery is starting more work, you need a law, not an opinion. Little's Law states that average WIP equals average throughput times average lead time. Rearrange it and the punchline appears: lead time equals WIP divided by throughput. At a steady throughput, the only way to shorten lead time is to lower WIP. That is why piling on more in-progress work makes everything finish later, not sooner. It also reframes the word executives hate: deliberate slack isn't idleness, it's the mechanism that pulls lead time down. Keep the team's own numbers handy, because the argument lands far better as "we hold twenty items and finish four a week, so things take about five weeks; cut WIP to twelve and we'd see three" than as an appeal to trust. The law turns a values debate about busyness into arithmetic anyone can check.

The business will still ask "when will it be done?" and a single date is a guess dressed up as a commitment. Use throughput percentiles instead. Take your weekly completed-item counts over recent history, look at how the work remaining could play out against that distribution, and answer with a range and a confidence level: "85 percent confidence it lands in three to five weeks." That is honest because it's built from how the team actually delivers, including its bad weeks. The phrasing matters so you don't sound evasive: lead with the confidence level, name the range, and say you'll refresh it as throughput data accrues. A defensible range beats a precise date that keeps slipping, and stakeholders learn to trust it precisely because it stops being wrong.

The thread of this unit: most of your lead time is waiting, and the levers that shorten it are flow efficiency, blocked time, WIP, and a percentile-based forecast, not faster typing. Next you'll move through a short cluster of practice: a quick pattern-spotting check on matching interventions to blocked-time and variability signals, a flow-efficiency calculation on real items, a live defense of cutting WIP using Little's Law, and a forecasting recommendation you could hand to your stakeholders. Before any of it, try one thing: pick three finished cards and estimate their flow efficiency out loud to your team, then watch how fast the talk turns from effort to waiting.