Delivery Intelligence reads a team’s own work-tracking data and shows where delivery actually gets stuck: where work waits, which priorities have inverted, and what an honest forecast looks like. It is one of the tools I build: not a product I sell, but the recurring analysis I used to do by hand, turned into software so the work does not need me in the room.

The screens below use synthetic demo data.

Leaders often reach for more utilisation when the real loss is waiting. In knowledge work a unit of work spends most of its life idle in a queue rather than being worked; Reinertsen puts active time at 5–15% of the total. So the gain is rarely exhorting people to work harder. It is finding the queues, the priority inversions, and the unplanned-work spiral before they set. And most delivery tools show status, not flow.

Every team, capability, value stream, and department in a single table: realistic planned-adjusted velocity, work in progress against capacity, queue length, the share of work that was actually planned, and whether stories are sized for their tier. Each cell is graded against thresholds drawn from the literature: planned work below 60% trips Kim’s “death spiral” red; work in progress past three-quarters of capacity flags the utilisation trap that Reinertsen’s queueing maths predicts.

Planning-health metrics for every team, rolled up to department. Each cell is graded against thresholds from the literature: red where planned work slips or a queue runs long. Synthetic demo data.

Lead time broken into its parts, team by team: time sitting in the backlog, waiting in Ready, in active development, and stuck at UAT. The coloured bar makes the queue time impossible to miss (it’s usually most of the bar). Beside it, flow diagnostics: flow efficiency, first-pass yield at the UAT handoff, cycle time against lead time, and the age of the oldest work in progress, each graded green, amber, or red.

Lead-time breakdown: active development against time spent waiting. Synthetic demo data.

Monthly added-versus-completed flow, with per-team flow efficiency, first-pass yield, and cycle time. Synthetic demo data.

Detail: flow efficiency, first-pass yield at UAT, cycle time and lead time, per team, each graded green, amber, or red. Synthetic demo data.

Every open story in priority order, each carrying an honest completion range rather than a false-precision single date, at team, capability, and value-stream levels. Where a high-priority item is blocked by something ranked below it—a priority inversion that delays the very thing you said mattered most—it is flagged in place. Cost-of-delay overlays let you re-sequence by Weighted Shortest Job First, so the economics decide the order rather than the loudest voice in planning.

Every open story in priority order, with team, capability, and value-stream range forecasts. Synthetic demo data.

Detail: a forecast inversion. The Team ETA (right column) lands earlier than the Capability ETA beside it, so the tool flags it (). The team’s local plan is running ahead of the wider queue. Synthetic demo data.

Spreading a team across concurrent efforts is rarely free, and the switching waste is only the first loss. Weinberg’s data puts it at 20% or more of capacity per additional concurrent project; run three at once and you could ship roughly twice as fast by doing one at a time. The bigger losses come after: start everything and nothing ships early, revenue and customer feedback arrive months later than they had to, and late feedback is how the wrong product gets built. I’ve charted Weinberg’s data and worked the full example separately. The tool prices what can be priced—switching waste and cost of delay—so “just start them all” stops reading as progress and starts reading as its true cost.

Each epic’s timeline over time, showing where work idles between bursts. Context-switching cost made visible and priced in cost-of-delay. Synthetic demo data.

A single-page application, no framework, that connects to a team’s own work-tracking tool through its API, caches locally for speed, and can push a re-prioritised backlog back. It is always deterministic—every figure reproducible and auditable, with no model in the loop—and grounded in named theory throughout: Reinertsen and Little on flow and queues, Goldratt on the constraint, Kim and the Accelerate research on unplanned work, DeMarco on range forecasting over single-point guesses, Karen Martin on first-pass yield. I design and build it myself. It began as analysis I did by hand for clients, and it exists so the work can run without me.

Delivery Intelligence needs a team’s delivery data in a tool like Shortcut, cleanly normalised—a real lift—so it belongs to embedded, hands-on work rather than a short fixed-scope diagnostic. But it is a straight look at how I read flow, and the kind of tooling I build so the change outlasts me.