Most teams running Kanban think they're tracking the right kanban metrics. They're not. Most boards display a count of cards in each column, an aging burndown nobody reads, and a velocity number lifted straight from Scrum. None of that tells you whether work actually flows. According to Atlassian and the Kanban Pocket Guide by Daniel Vacanti, four numbers separate teams that ship predictably from teams that miss every commitment: throughput, cycle time, work in progress, and work item age. Master those four kanban metrics — and the deeper analytics built on top of them — and you can forecast delivery, find bottlenecks before they become disasters, and stop guessing about when work will be done.
This guide walks through every kanban metric that matters in 2026, what healthy ranges look like, and how AI-powered analytics are automating the measurement work that used to consume Scrum Masters and delivery leads.
What are the core kanban metrics?
The four foundational kanban metrics every flow-based team should track are throughput (work items finished per unit of time), cycle time (elapsed time from start to finish for a work item), work in progress (number of items started but not finished), and work item age (elapsed time a started item has been in flight). Together, they describe the health of your delivery system using the language of flow, not output.
That definition comes straight from Daniel Vacanti's Kanban Pocket Guide, the closest thing Kanban has to a canonical text. ProKanban.org and Kanban University endorse the same four. If your tool tracks something else and calls it a kanban metric, it's probably a vanity number.
Why these four and not velocity
Velocity is a Scrum artifact tied to story points and sprint boundaries. It rewards estimation theater and punishes teams who finish work mid-sprint. In a continuous flow system there are no sprints to bound it, no story points to inflate, and no commitment to break. Throughput counts what actually shipped. That's the metric that matters when teams adopt Kanban — and it's especially relevant now that AI-augmented development is making story-point velocity meaningless because the human estimate no longer matches the AI-assisted reality.
Throughput in kanban: how much work your team finishes
Throughput is the average number of completed work items delivered per unit of time — usually per day, per week, or per sprint-equivalent. According to Wrike's Kanban Guide, only fully completed items count toward throughput. Items still in progress don't.
How to calculate throughput
Pick a time window — one week is the standard. Count every item that crossed the done line during that window. That's your throughput.
A few rules that keep the metric honest:
Count whole items, not story points or T-shirt sizes. Throughput's power comes from treating items as roughly equal-sized units.
Only count completions inside the window, regardless of when the item started.
Track the variability, not just the average. A team with 5 items per week ±1 is healthier than a team with 5 items per week ±4.
What healthy throughput in kanban looks like
There is no universal good throughput number — it depends on item size and team composition. What matters is consistency. A high-functioning team's weekly throughput sits inside a tight band; the 50th-to-85th percentile range should span no more than 2–3x. When the band is wider than 4–5x, your delivery system is unpredictable and forecasting is unreliable.
Throughput and AI delivery
Teams adopting AI coding assistants like Copilot, Cursor, and Claude Code are seeing throughput jump 30–60% on similarly scoped work — but only when their definition of done holds steady. Many teams celebrate the throughput spike and quietly ship more defects. The DORA 2025 report flagged this trend explicitly: AI-augmented teams ship faster but show higher change failure rates unless they invest in quality gates. Track throughput alongside escaped-defect counts, or you'll mistake speed for progress.
Cycle time in kanban: how fast each item moves
Cycle time is the elapsed time between when a work item starts and when it finishes. Starts usually means the moment a card enters the first active column on your board (e.g., In Progress), and finishes means the moment it crosses the done line.
Lead time vs cycle time
Practitioners frequently confuse the two. The clearest way to keep them straight: cycle time starts the clock when work begins; lead time starts the clock when the customer or team commits to the work. Lead time always includes some queue time before work starts; cycle time strips that out.
According to Nave's reference data, healthy software teams typically run cycle times of 5–10 days and lead times of 10–20 days. A widely-cited r/agile thread surfaced one team running 23-day cycle times and 51-day lead times — a sign of severe queueing and a flow system that's broken.
What is a good cycle time in kanban
A good kanban cycle time depends on team and item size, but as a benchmark, software teams should aim for 85% of work items to complete within 14 days, 95% within 30 days, and a median (50th percentile) under 5 days. Wider distributions indicate hidden queues, dependency bottlenecks, or scope inflation that should be addressed in retrospectives.
How to use cycle time scatterplots
A scatterplot of cycle time per item — completion date on the X-axis, cycle time on the Y-axis — instantly shows you outliers. Pick any item above the 85th percentile and ask: what made this one slow? Was it blocked? Did it span multiple specialists? Did the scope grow mid-flight? The scatterplot is the single most useful kanban analytics view because it surfaces the exceptions where flow broke down.
Work in progress: the metric that controls everything else
WIP is the count of items currently in progress — started but not finished. Unlike throughput and cycle time, WIP is something you set, not just measure. A WIP limit caps the number of items the team can have in flight at once.
Little's Law and why WIP matters
Little's Law states that average cycle time = average WIP / average throughput. Reduce WIP, and cycle time drops. Increase throughput at the same WIP, and cycle time also drops. This isn't an opinion — it's a mathematical relationship that holds in any stable flow system.
The practical implication: if your cycle times are getting longer, your team almost certainly has too much work in progress. The fix isn't to work harder. The fix is to stop starting and start finishing.
Setting healthy WIP limits
A common starting point is a per-column WIP limit of roughly 1.5x the number of people who pull from that column. So if three developers pull from In Progress, set the limit at 4 or 5. Tighten limits over time as the team gets comfortable saying I'll pick that up when I finish what I'm on.
WIP and AI-augmented teams
When AI accelerates individual coding, teams sometimes assume they should raise WIP limits to use the extra capacity. That's almost always wrong. The bottleneck shifts from coding to review, integration, and testing — pulling more in just clogs those downstream stages. Smart AI-augmented teams keep WIP limits flat or lower them, and use the freed capacity to invest in better quality gates and faster feedback loops.
Work item age: the early-warning system most teams ignore
Work item age is the elapsed time a currently-in-progress item has been in flight. Unlike cycle time — which you measure after items finish — work item age is a real-time metric you check every day.
Why work item age beats burndown charts
A daily standup that asks how old is each in-flight item? surfaces problems before they show up in finished metrics. If your team's 85th-percentile cycle time is 14 days and an item has been in progress for 12 days, it's near the danger zone. Investigate now.
ProKanban.org's flow practice explicitly elevates work item age over traditional standup formats. Instead of round-robin what did you do yesterday?, the standup asks: Which items are aging? What's blocking them? What can we do today to move them forward? Teams that adopt this format routinely report 20–30% reductions in cycle time within a few weeks because aging items get attention before they fall off the cliff.
How to visualize work item age
Most modern Kanban tools — Jira, Azure DevOps, Linear, Businessmap, Nave, Teamhood — provide an aging WIP chart that plots each in-progress card by age, with reference lines at the 50th, 70th, 85th, and 95th percentiles of historical cycle time. Items above the 85th line need attention. Items above the 95th line are a crisis — escalate or split.
Flow efficiency: the metric that exposes hidden waste
Definition and formula
Flow efficiency = (Active Time / Total Lead Time) × 100%
If a story takes 12 days to complete but only 3 days of actual work, flow efficiency is 25%. The other 75% was spent waiting — for a code review, a deployment slot, a clarification, an approval, a build to finish.
What healthy flow efficiency looks like
According to Kanban University and a much-cited 2023 ASOS Tech Blog study covering 60+ teams, typical software teams operate at 15–40% flow efficiency. Teams above 40% are exceptional. Anything below 15% indicates severe queueing and is usually fixable by removing handoffs, reducing dependencies, or shrinking review queues.
The metric is contested — Nick Brown's ASOS analysis flagged real measurement problems at scale — but the directional signal is reliable: if your flow efficiency is dropping, your team is spending more time waiting and less time working. Find the queues and unjam them.
Flow efficiency in AI-augmented delivery
AI accelerates the active-work portion of flow efficiency dramatically. A developer with Copilot or Cursor can write the same feature in 40% less active time. But total lead time often barely budges, because the queue stages — review, deployment, QA — didn't get faster. Flow efficiency drops as a result. This is one of the clearest metrics for proving that AI productivity gains evaporate inside organizational bottlenecks, and one of the strongest arguments for redesigning your delivery system around AI rather than just bolting AI onto it.
Cumulative flow diagrams: the dashboard view
A cumulative flow diagram (CFD) plots the count of items in each board column over time as stacked colored bands. It's the single most information-dense kanban metric visualization.
What to look for:
Smoothly widening bands mean healthy flow.
A band that bulges wider means a queue is building up; that column is becoming a bottleneck.
Parallel diagonal lines mean stable arrival rate matches stable departure rate. That's good.
Diverging lines mean arrivals are outpacing completions; WIP is climbing and cycle times will follow.
CFDs let you see queue formation in real time, before it shows up as a missed delivery date. Every serious Kanban tool — Atlassian Jira, Targetprocess, Kanban Tool, Businessmap, Nave — generates CFDs automatically.
How to use kanban metrics for forecasting
Monte Carlo forecasting
Forget rolling up story-point estimates. The modern kanban approach to forecasting is Monte Carlo simulation: take your team's historical throughput distribution, run 10,000 simulated futures, and report a probability range.
A typical Monte Carlo output looks like this: 85% probability we finish 22 items by March 15, 50% probability we finish 27, 15% probability we finish 32. Stakeholders get a probability-weighted commitment instead of a fragile point estimate, and the team forecasts using actual delivery data instead of optimistic guesses.
Tools like ActionableAgile, Nave, KanbanFlow, and Businessmap run Monte Carlos automatically once you've collected 8–12 weeks of throughput data. As Daniel Vacanti and Scrum.org have documented, Monte Carlo forecasting is now standard practice for high-performing kanban teams — and it works equally well inside Scrum sprints if you swap velocity for throughput.
How much data you need
You need at least 8–12 weeks of throughput history before Monte Carlo forecasts get reliable. Less than that, and the simulation gets dominated by random noise. Teams just starting Kanban should commit to 60–90 days of measurement before relying on forecasts for stakeholder commitments.
How AI is changing kanban metrics in 2026
The biggest shift in kanban metrics over the past 18 months is the emergence of AI-powered analytics layers sitting on top of Jira, Linear, GitHub Issues, and Azure DevOps. Tools like Nave, Businessmap, Teamhood, Atlassian Intelligence, and Linear's AI features are automating three things that used to consume hours of manual work each sprint:
Bottleneck detection. AI watches your CFD and aging WIP charts continuously and flags emerging queues before humans notice them.
Anomaly explanation. When a metric spikes, the AI looks at the underlying tickets, comments, and pull requests to suggest why — for example, 5 of the 7 outlier items this week were blocked on database migrations.
Auto-generated retrospective insights. Instead of teams brainstorming what went wrong, the AI summarizes metric movements and proposes specific improvement experiments.
This is exactly the area where Agile training has lagged. Most certified Scrum Masters and Kanban practitioners learned metrics in a pre-AI world and don't know how to interpret AI-augmented analytics dashboards. FixAgile, an Agile training and implementation framework designed for the age of AI, builds AI-readiness into every metrics-focused track — covering both the foundational flow metrics and the modern analytics layer that AI tools provide.
What AI cannot replace
AI is excellent at surfacing the what of a metric movement. It still struggles with the why — the human conversations, the cross-team politics, the unspoken decisions that produce the queues. Scrum Masters, Release Train Engineers, and delivery leads who learn to combine AI-generated insights with human investigation are the ones leading the highest-performing teams in 2026. The metric stack is becoming AI-native; the improvement work remains stubbornly human.
Common kanban metrics mistakes to avoid
Tracking output, not flow. Counting tickets closed without measuring cycle time gives you a productivity vanity number. Throughput without cycle time is just velocity in disguise.
Ignoring variability. A team with predictable cycle times beats a team with faster averages but wider distributions, because predictability is what stakeholders pay for.
Setting WIP limits per person. WIP limits should be per column or per swim lane, not per person. Per-person limits encourage solo work and discourage swarming on aging items.
Using burndown charts on a Kanban board. Burndowns assume sprint commitments and don't visualize flow. Use a CFD and an aging WIP chart instead.
Forecasting from too little data. Monte Carlo simulations need 8–12 weeks of throughput. Teams that forecast from 2–3 weeks of data get noise-dominated results and lose stakeholder trust.
Treating metrics as a performance review tool. The moment metrics become individual evaluation, teams game them. Throughput goes up while quality collapses. Keep kanban metrics at the system level, not the individual level.
A kanban metric stack for 2026
For a flow-based team starting from scratch, here's the minimum kanban metric stack worth implementing:
Daily: work item age, reviewed at standup against the team's 85th-percentile cycle time.
Weekly: throughput count and cycle time scatterplot.
Bi-weekly: cumulative flow diagram and WIP-limit adherence review.
Monthly: flow efficiency and Monte Carlo forecast refresh.
Quarterly: full retrospective on metric trends and at least one improvement experiment per quarter targeting the weakest metric.
Mature teams add escaped-defect rate, change failure rate (DORA), and customer-value-delivered alongside the flow stack to balance speed against quality and outcome.
The bottom line
Kanban metrics aren't paperwork. They're the early-warning system that lets flow-based teams see problems before deadlines slip, predict delivery before stakeholders ask, and improve their system before it stops working. Throughput, cycle time, WIP, and work item age form the foundation. Flow efficiency, cumulative flow diagrams, and Monte Carlo forecasts add forecasting power. AI-powered analytics tools automate the measurement and surface bottlenecks faster than any human review.
But buying a tool isn't the same as adopting flow metrics. Most teams that fail at kanban metrics fail because nobody on the team knows how to read the charts, set healthy WIP limits, or run a metric-driven retrospective. That's a training gap, not a tooling gap.
If your team is drowning in lagging Scrum reports, struggling to forecast in an AI-accelerated delivery world, or running a Kanban board with flow metrics that nobody trusts, this is exactly what FixAgile's training programs are built to solve. Our AI-era Kanban and metrics tracks teach teams to measure flow, interpret AI-powered analytics, and turn metrics into continuous improvement — not dashboards nobody reads.
