Metrics and Continuous Improvement

In the last unit you managed flow by watching queues and feel. Now you make it measurable. Four numbers do most of the work, and the moment a stakeholder asks "how long does this take?" or "are we getting faster?", you reach for them.

Lead time is the customer's clock: from the moment a request enters your system until it's delivered. Cycle time is the team's clock: from when work actually starts until it's done. The gap between the two is pure waiting, the time an item sits in a queue before anyone touches it.

Throughput is how many items you finish per week, and WIP, from the last unit, is how many are open right now. Lead and cycle time tell you how long work takes; throughput tells you how much gets done. Together they let you answer delivery questions with evidence instead of optimism.

• Dan: Leadership wants to know why "two-day tasks" take three weeks to land.
• Nova: Two different clocks. Cycle time is the two days we're actually working it. Lead time is the three weeks the customer waits, start to finish.
• Dan: So the gap is all waiting before we even pick it up.
• Nova: Right, and that's the number to chase. Throughput says how many we finish a week; the gap says where the time actually goes.
• Dan: Then I should be reporting lead time, not how fast we code.

Notice that Nova reports the number the business actually feels, not how busy the team looks. Most of your improvement leverage lives in that gap between the two clocks.

The fastest way to see all of this at once is a cumulative flow diagram (CFD): a stacked area chart with one band per column, each plotting the cumulative count of items that have reached that stage over time. You don't read it cell by cell; you read its shape.

Three readings matter. The vertical thickness of all the bands together is your total WIP on any date. The horizontal distance between the top curve (arrived) and the bottom curve (departed) approximates lead time. And the width of a single band shows how much work is parked in that stage. Healthy flow looks like smooth, roughly parallel bands climbing together. When one band starts widening, WIP is piling up there and a queue is forming. When a band goes flat, that stage has stalled or starved. One glance tells you whether the system is stable or quietly degrading.

Metrics tempt you to overreact. One slow week is not a trend, and the worst thing you can do is yank a lever every time a number twitches. Your job is to separate signal from noise by reading direction over several weeks, not the latest snapshot.

Watch for three movements. Cycle time creeping up sprint after sprint means work is taking longer to clear. Growing variability, the spread between your fast and slow items widening, means delivery is getting less predictable even if the average holds. And a slowly rising WIP usually precedes both, because more open work always lengthens the queue. When you spot one, resist reporting the raw number and instead name the most likely cause: a new dependency, a thinned-out review stage, a surge of unplanned support. A trend tied to a plausible cause is something leadership can act on; a data dump is not.

Kanban improves by evolution, not revolution, so once a trend points somewhere, you don't mandate a fix, you run an experiment. Frame it the way you'd want one framed for you: a clear hypothesis ("if we lower the review WIP limit to two, cycle time drops"), one variable changed, a fixed window to watch, the specific metric you'll judge it by, and a defined rollback if it doesn't pan out. That structure is what turns a risky-sounding change into something a cautious manager will agree to, because nothing is permanent and the cost of being wrong is a single sprint.

The thread holding this unit together: measure flow with a few honest numbers, read the trend rather than the twitch, and let what you see drive small, reversible experiments. You'll work that loop across several practices ahead, first reading what different CFD shapes are telling you, then building a lean metrics dashboard and a trend read you could hand to leadership, and finally pitching a WIP experiment live to a manager who needs the rollback spelled out. Before the next number lands on your desk, try asking of it: trend or noise, and if it's a trend, what's the smallest experiment that would test the cause?