A guide for delivery managers, engineering leaders, product owners and transformation sponsors. Which Kanban metrics tell you something you can act on, which ones only look like measurement, and how to commit to a date without asking anyone for an estimate.
The short answer
Most writing on this subject stops at the list. The harder question, and the one a delivery manager actually faces on a Tuesday morning, is which number to look at when something is going wrong, and what to do once you have looked.
That is where the four metrics separate. Three of them are historical. They describe work that has already finished, so by the time they move, the outcome is settled and your only option is to learn from it. One of them, work item age, describes work that is still in flight, while the result can still be changed. It is the least established of the four, it is missing from most default board views, and adding it is usually the highest-value change a team can make to how it runs a board.
What Kanban metrics actually measure
Kanban metrics measure the movement of work through a system. They do not measure effort, activity or how busy anyone is. That is a deliberate design choice, and it is why they behave so differently from the metrics most enterprises inherited from traditional project management.
Two consequences follow, and both catch teams out.
Every flow metric depends on a boundary you have to define. Cycle time is measured from when an item started to when it finished, so a team that has not agreed what "started" means cannot measure it. This is not pedantry. If one team starts the clock when an item is pulled into analysis and another starts it when a developer opens the branch, their cycle times are not comparable, and neither is their throughput, because the same work crosses the boundary at different moments. Write the two definitions down, put them next to the board, and revisit them when the workflow changes.
None of the four requires an estimate. A start date, a finish date and a count are enough to produce all four metrics and every forecast built on them. This is the property that makes flow metrics unusually resistant to the distortions that affect self-reported measures, and it is the reason they hold up in environments where estimation has become political.
The four flow metrics
The definitions below are the ones given in the Kanban Guide, whose May 2025 revision was authored by a group including Daniel Vacanti, John Coleman, Julia Wester and Prateek Singh. The columns after them are the part the guide does not give you: what each metric is for, and how each one is usually broken in practice.
| Metric | Definition | Question it answers | Timing | How it gets broken |
|---|---|---|---|---|
| Work in progress | The number of work items started but not finished | How much are we trying to do at once? | Current state | Counting only visible cards, and excluding blocked or waiting items that are very much still started |
| Cycle time | The elapsed time between when a work item started and when it finished | How long does work take once we begin it? | Lagging | Reported as an average, which hides the long tail that actually breaks dates |
| Work item age | The elapsed time between when a work item started and the current date | Which item in flight is in trouble right now? | Leading | Not measured at all, in most organisations |
| Throughput | The number of work items finished per unit of time | How much do we actually deliver? | Lagging | Converted into story points, which quietly reintroduces estimation |
Note what the guide says about throughput: it is an exact count of work items. Not points, not hours, not weighted effort. The moment you weight it, you have made it depend on judgement, and you have lost the property that made it trustworthy.
Work item age: the only one you can still act on
Work item age is the elapsed time since an item started, for an item that has not finished. It is the only flow metric that describes something you can still influence, and it is the one teams are least likely to be tracking.
Here is the practice that makes it useful. Take the cycle time distribution for finished work of the same type, and find the 85th percentile. Suppose it is 16 days. Now sort everything currently in progress by age, oldest first, and compare each item against that number. An item that has been running for 14 days is not merely old. It is two days away from becoming an outlier, and you still have those two days.
This converts the standup from a status ritual into a triage decision. The question stops being "what did you do yesterday" and becomes "this item is at 14 days against an 85th percentile of 16, so what happens to it today". The available answers are concrete: remove the block, split the item so part of it can finish, put a second person on it, or make an explicit decision to let it run long and tell whoever is waiting. Any of those is better than discovering the overrun after the fact.
Most teams never do this for a mundane reason. Board tools display position, not age, so a card that has sat in the same column for three weeks looks identical to one that arrived this morning. Until age is visible, it will not be managed.
Is there such a thing as Kanban velocity?
No, not in any definition Kanban provides for itself. The word velocity does not appear in the Kanban Guide. Velocity is a Scrum measure: story points completed per sprint. Kanban has neither sprints nor a requirement to size anything, so the measure has nothing to attach to.
The question is asked constantly, though, and for understandable reasons. Teams moving from Scrum to Kanban lose a number their stakeholders had learned to read. Some tools continue to offer velocity charts on Kanban boards, and some add-ons market a "Kanban velocity" report. So the term persists in the market even though it has no standing in the method.
The metric you are looking for is throughput. It answers the same management question, how much work gets done in a period, without any of velocity's dependencies.
| Velocity | Throughput | |
|---|---|---|
| What it counts | Story points completed per sprint | Work items finished per unit of time |
| What it requires | Every item estimated, on a scale the team shares | A start date and a finish date |
| Time basis | A fixed sprint boundary | Any window, including a rolling one |
| Comparable between teams | No, point scales are local to a team | With care, if the work item types are similar |
| Distorted by | Estimate inflation, which is invisible | Splitting items smaller, which shows up in cycle time |
| Used to forecast by | Multiplying average velocity by remaining points | Sampling the historical distribution of past throughput |
If a stakeholder asks for velocity, the honest translation is a pair of numbers rather than one: throughput tells them how much finishes per week, and a cycle time percentile tells them how long any single item takes. Together those answer more than velocity ever did, because velocity conflates the two and reports neither reliably.
One caveat, in fairness. Some teams do measure throughput in story points and call the result velocity, and if their estimates are stable this is not useless. But it costs them the property that made the metric trustworthy: the number now moves when estimating behaviour changes, not only when delivery changes. If you keep it, keep unweighted item counts alongside it so you can see the two diverge.
Little's Law, and the conditions that break it
Little's Law relates three of the four metrics:
Most articles quote it here and move on. That is where the damage happens, because the relationship only holds under conditions that a real delivery system frequently violates. Daniel Vacanti, who wrote the standard treatment of these metrics, sets out the assumptions behind it and calls the habit of applying the formula regardless "Little's Flaw".
The conditions are roughly these. The rate at which work arrives should match the rate at which it departs. Everything that starts must eventually finish, rather than being abandoned in place. Work in progress should be about the same at the start and the end of the period you are measuring. The average age of the work in progress should be neither climbing nor falling. And all three quantities must use consistent units, so you cannot measure cycle time in days and throughput per week and expect the arithmetic to mean anything.
Delivery systems break these routinely. Work gets started and quietly abandoned. Someone injects an urgent request that lifts work in progress by half. A team stops finishing anything for a fortnight while it waits on a dependency, and the average age of everything in progress climbs.
So treat Little's Law as a design tool rather than a calculator. Do not use it to compute a delivery date. Use it to reason about direction: if throughput stays roughly where it is and you cut work in progress, cycle time falls. That single relationship is the entire argument for WIP limits, and it is enough on its own to justify them.
Which chart answers which question
Four charts carry the four metrics. Choosing between them is easier if you start from the question rather than the chart.
| Chart | Question it answers | What to read |
|---|---|---|
| Cycle time scatterplot | How long does work take, and how variable is it? | The percentile lines, and the outliers sitting above them |
| Work item aging chart | What is at risk right now? | Items whose age is approaching your cycle time percentile |
| Cumulative flow diagram | Is work piling up, and where? | Bands that widen over time, and a flat finished line |
| Throughput run chart | Is delivery steady enough to forecast from? | Consistency of the pattern, not the direction of a trend line |
Jira, Azure DevOps and dedicated flow analytics tools all produce cumulative flow diagrams and throughput charts. Scatterplots and aging charts are less commonly built in, which is part of why the two most useful views are the two least used. If your tooling does not draw them, both can be produced from an export containing one row per item with a start date and a finish date.
The scatterplot deserves particular attention, because it is where the most common reporting error becomes visible.
Cycle time data is almost never symmetrical. A few items go badly wrong and drag the average upward, which means the average is beaten by considerably more than half the work and missed by a minority larger than most managers expect. Reporting "our average cycle time is 10 days" therefore describes neither the typical case nor the risk. Percentiles describe both: half the work finishes within 8 days, 85% within 16, 95% within 26.
Forecasting delivery without estimates
Two techniques follow directly from the metrics above, and neither needs anyone to size anything.
A service level expectation is a percentile stated as a commitment: "85% of items of this type finish within 16 days of being started." It is derived entirely from your own history, it comes with an explicit confidence level, and it gives the team a threshold against which to read work item age. This is the smallest useful forecasting artefact a Kanban team can produce, and most can produce it in an afternoon.
Monte Carlo simulation answers the larger question. Given a set of remaining items, it samples your historical throughput many times over to produce a distribution of completion dates, so the output is "an 85% chance of finishing by 14 March" rather than a single date presented with false confidence. The input is a list of past weekly throughput counts. That is all.
The advantage over velocity arithmetic is not mainly accuracy, though it usually is more accurate. It is that the answer arrives with its uncertainty attached. Multiplying average velocity by remaining points produces one number that looks precise, inherits every estimation error in the backlog, and tells the recipient nothing about how likely it is.
Two honest limits. Both techniques assume the near future resembles the recent past, so a reorganisation, a change of work type or a significant team change invalidates the history. And both need enough data to sample from, which in practice means a few months of consistent measurement rather than a few weeks.
Measuring flow when AI is in the delivery loop
Flow metrics have held up unusually well through the arrival of AI-assisted development, and the reason is structural. They count finished items and elapsed calendar time. Neither responds to how the work was produced, so neither can be inflated by generating more output.
Activity metrics do not have that property. Commits, pull requests, lines changed and tickets touched all rise when a coding assistant is in use, whether or not anything reaches a customer sooner. An organisation measuring activity will therefore see a productivity improvement almost immediately, and it will not mean anything.
The evidence supports treating a rising delivery number with care. Google's DORA research programme, in its 2025 State of AI-assisted Software Development report, found AI adoption associated with higher software delivery throughput and at the same time with lower delivery stability. Both movements come from the same adoption. So more items finishing per week is consistent with AI working, and equally consistent with a team shipping faster than its review and testing can absorb. What to do about that second case, and where work in progress limits belong once the constraint moves downstream, is covered in Does Kanban still work when AI does the work?
Three practical adjustments follow. Watch the shape of the cycle time distribution rather than its centre, because the first sign of trouble is usually a fatter tail rather than a worse median. Check that the finish boundary still means what it did, since rework that moves downstream of "done" leaves cycle time looking better while the system gets worse. And treat any self-reported productivity gain as a hypothesis to test rather than a result, a point reinforced by METR's 2025 randomised trial, in which experienced developers' estimates of their own speed diverged sharply from what was measured. METR has since published an update cautioning that selection effects limit what that study says about current tools, which makes the perception gap, rather than any particular percentage, the durable finding.
The wider measurement question, covering cost, business outcome and what a finance function will accept as evidence, is the subject of a companion article: DevOps Metrics in 2026: What to Measure When AI Writes the Code.
Metrics that mislead
Some of the most commonly recommended Kanban measures are either borrowed from a method with different assumptions or actively counterproductive.
- Burndown charts. A burndown tracks a fixed scope against a fixed timebox. Kanban has neither, so the chart either flattens into noise or forces you to invent a scope boundary the method deliberately avoids. This is a Scrum artefact and it belongs there.
- Average cycle time. Right-skewed data has no meaningful average. Use percentiles, and always report which one.
- Utilisation. Keeping everyone busy is the most reliable way to lengthen queues. As utilisation approaches capacity, waiting time rises sharply, so a system optimised for busy people delivers more slowly than one with slack in it.
- Individual throughput. Work items are not uniform, so counting them per person measures the allocation of work rather than the contribution of the person, and it prices in an incentive to take small items and avoid hard ones.
- Story points as a target. Any estimate that becomes a target stops being an estimate. Points inflate quietly and nothing in the data reveals it.
- Time tracking. Hours logged measures effort, not flow. It answers a cost accounting question, which is legitimate, but it says nothing about how quickly work moves through the system and should not sit in a flow dashboard.
How to start in four weeks
Instrumentation is usually the easy part. Agreement is not. This sequence front-loads the decisions.
- Week one, define the boundaries. Agree exactly what "started" and "finished" mean for your workflow, write both definitions where the team can see them, and settle how blocked and abandoned items are treated. Nothing downstream is meaningful until this is done.
- Week two, extract and plot. Pull one row per completed item with its start and finish dates, covering as much history as those definitions remain valid for. Plot the scatterplot and calculate the 50th, 85th and 95th percentiles.
- Week three, make age visible. Add work item age to the daily standup and walk the board oldest item first. Change nothing else. The conversation will change on its own.
- Week four, publish a service level expectation. State it at the 85th percentile, share it with the people who depend on the team, and start tracking how often it holds.
Introduce WIP limits after this rather than before. Set early, they are a guess that becomes policy. Set once you can see cycle time and age, they become an adjustable control with a feedback loop attached, and you can demonstrate what tightening them actually bought.
Work with MASSIVUE
MASSIVUE works with enterprises on transformation delivery, where the recurring problem is not the absence of metrics but the presence of the wrong ones: dashboards full of activity measures that rise reliably and explain nothing. The distinction this article draws, between measures of flow and measures of effort, is the one that determines whether a delivery report survives contact with a finance function or an executive committee.
Two MASSIVUE Academy micro-credentials cover this ground directly. AI-Powered Program & Delivery Management covers using AI in delivery without fooling yourself about the productivity gains, which is precisely the measurement discipline described above. Pragmatic Product Ownership is aimed at the managers and sponsors who set the authority boundary product owners work inside, which matters here because WIP limits fail wherever work can be injected around them.
Related reading: Does Kanban Still Work When AI Does the Work?, DevOps Metrics in 2026, and The Measure of a Developer: Beyond Just Productivity Metrics.
Frequently asked questions
What are the four Kanban metrics?
Work in progress, cycle time, work item age and throughput. The Kanban Guide names these four as the mandatory flow metrics and permits additional context-specific measures alongside them. Every standard Kanban chart, including the cumulative flow diagram and the throughput run chart, is derived from these four.
Does Kanban have velocity?
No. Velocity is a Scrum measure of story points completed per sprint, and Kanban has neither sprints nor mandatory estimation. The equivalent Kanban measure is throughput, which counts finished work items per unit of time and requires no estimates. Some tools offer velocity charts on Kanban boards, but the metric has no standing in the method itself.
What is the difference between lead time and cycle time?
Cycle time is measured from when work starts to when it finishes, so it covers the part of the process the team controls. Lead time is normally measured from when the customer made the request, so it includes the time an item spent waiting in the backlog before anyone touched it. Lead time is what the customer experiences, cycle time is what the team manages, and the gap between them is queue time. The Kanban Guide defines cycle time and does not define lead time, so if you use the term, state your start point explicitly.
How do you calculate throughput in Kanban?
Count the work items that reached your finish boundary within a chosen period, typically a week. That is the whole calculation. Do not weight the count by size, points or effort, because the Kanban Guide defines throughput as an exact count of work items and weighting reintroduces the estimation dependency the metric exists to avoid.
What is a good cycle time?
There is no external benchmark worth using, because cycle time depends entirely on how you defined your start and finish boundaries and on the type of work you do. The useful comparison is against your own history: whether the 85th percentile is falling, and whether the distribution is getting tighter. A team whose 85th percentile drops from 24 days to 16 has improved regardless of what any industry figure says.
Can you use Kanban metrics with a Scrum team?
Yes, and it is common. The four flow metrics apply to any workflow with a definable start and finish, sprints included. Teams typically add work item age to the daily scrum and use throughput and cycle time percentiles for forecasting, either alongside velocity or in place of it. Nothing in Scrum prevents this.
How many items should be in progress at once?
Fewer than you currently have, in almost every case. Rather than adopting a formula, set a limit slightly below your observed average work in progress, watch what cycle time does over the following weeks, and adjust. Little's Law predicts the direction of the change, and your own scatterplot will confirm whether it happened.
Sources: the flow metric definitions are taken from the Kanban Guide (May 2025 revision). Delivery throughput and stability findings are from DORA's 2025 State of AI-assisted Software Development report. The developer perception findings are from METR's July 2025 randomised controlled trial and its February 2026 update. Figures used in the charts are illustrative worked examples, not measurements from a client engagement.