Kanban Flow Metrics: Cycle Time, Throughput and CFDs

Measure kanban flow metrics: WIP, throughput, work item age, cycle time and lead time, and read a cumulative flow diagram to find where work stalls.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Kanban flow metrics tell you how work moves through your system: how much is in progress, how fast it finishes, how long it takes, and which items are getting old. The Kanban Guide names four mandatory flow metrics: WIP, "the number of work items started but not finished"; throughput, the number finished per unit of time; work item age, the time since an item started; and cycle time, the time between an item's start and finish (The Kanban Guide). Measuring them is part of the "Manage Flow" practice described on the Kanban method page.

The metrics depend on definitions. Kanban cycle time and kanban lead time are used differently by different sources. The Kanban Guide uses cycle time for the span from started to finished and lets teams rename the metrics if they use them as described. Kanban University's guide uses lead time for "the time it takes for a single work item to pass through the system from the start (commitment point) to completion," and distinguishes customer lead time, from request to delivery, from system lead time (Official Guide to The Kanban Method). Pick your terms, write down the start and finish points, and use them consistently.

Each metric answers a different question. WIP shows load. Kanban throughput shows delivery rate, and the Kanban Guide notes it is the exact count of work items. Cycle time, looked at as a distribution, shows how predictable the system is. Work item age is the only one of the four that measures time for items still in progress, which makes it the early warning: an item that is already older than most finished items is at risk.

The cumulative flow diagram brings several of these together in one chart. It plots the count of items in each state over time, so you can see WIP growing, a stage becoming a bottleneck, or delivery stalling. Used with a cycle time scatterplot and an aging view, it gives a team enough to run evidence-based improvement without a large metrics program.

How It Works

Every metric comes from two timestamps per item: when it started and when it finished, as your Definition of Workflow defines those points. Recording the date an item enters each column adds detail for the cumulative flow diagram and for finding where time goes. Most board tools store these dates; a physical board needs someone to write the dates on cards.

Cycle time is calculated for each finished item as finish date minus start date. Teams usually count in days and decide whether the start and finish days both count. Plotting each finished item as a dot, with finish date on one axis and cycle time on the other, gives a scatterplot that shows spread and trends. Kanban University's guide describes the related run chart and lead time distribution, and notes the aim of narrowing the distribution for predictability and shifting it left for timeliness.

A service level expectation turns that history into a forecast for a single item. The Kanban Guide defines an SLE as a period of elapsed time plus a probability, such as "85% of work items will be finished in eight days or less," based on historical cycle time (The Kanban Guide). You find it by reading the cycle time at the chosen percentile of your recent finished items. The Guide also lists keeping items from aging unnecessarily, using the SLE as a reference, as part of actively managing work.

Throughput is the count of items finished per day or week. It varies naturally, so look at it as a range over several periods. Little's Law links the metrics: the average number of items in a system equals their average arrival rate multiplied by their average time in the system, and in a stable system where arrivals match departures, throughput stands in for the arrival rate (Little, Little's Law at 50). If WIP rises while throughput stays flat, cycle time will rise too.

The cumulative flow diagram stacks a band for each state, with time on the horizontal axis and item count on the vertical. Atlassian's documentation says that an area widening vertically over time generally marks a bottleneck in that column (Atlassian, cumulative flow diagram). Kanban University adds that parallel lines indicate inflow consistent with outflow. If the line marking finished work goes flat, nothing is finishing; if the arrivals line climbs faster than the finished line, work is entering faster than it leaves.

Daniel Vacanti's book Actionable Agile Metrics for Predictability covers these charts, Little's Law and forecasting with flow metrics in depth and is a good next step once the basics are in place.

Step-by-Step Guide

Step 1: Define start and finish points

Agree where an item starts, usually the commitment point, and where it finishes, usually delivery. Write both into your board policies. If you also want customer lead time, record when the request arrived. Changing these points later breaks comparisons, so choose deliberately.

Step 2: Record dates for every item

Make sure each card captures its start date, its finish date and, ideally, the date it enters each column. Check that your tool records column changes or add a simple log. Include items that were abandoned so they do not quietly disappear from the data.

Step 3: Calculate cycle time for finished items

For each finished item, subtract the start date from the finish date. Keep the raw list; averages hide the spread that matters. Split by work type if different types follow different paths, because mixing them blurs both.

Step 4: Plot a cycle time scatterplot

Plot each finished item by finish date and cycle time. Draw lines at a few percentiles of the data so the team can see what most items achieve. Look for outliers and ask what happened to them.

Step 5: Track throughput and WIP

Count finished items per week and chart the count over time. Record WIP at the same interval. Compare the two: rising WIP with flat throughput predicts longer cycle times.

Step 6: Build a cumulative flow diagram

Chart the number of items in each state for each day. Read the bands from the bottom up: finished work, then each stage, then arrivals. Watch for bands that widen, a finished line that goes flat, and a growing gap between arrivals and departures.

Step 7: Watch work item age every day

For each item in progress, show how long it has been since it started. Compare it with your cycle time history or SLE. Discuss the oldest items first at the daily meeting and decide what would move them.

Step 8: Set an SLE and review metrics on a cadence

Once you have a few weeks of finished items, choose a percentile and read off the matching cycle time as your SLE. Share it with stakeholders as a forecast that carries a stated probability. Review the charts in your service delivery review and pick one experiment to improve flow.

Best Practices

• Look at distributions. A single average hides the long tail of slow items that stakeholders actually notice.
• Count finished items. The Kanban Guide defines throughput as an exact count of work items, which avoids arguments over sizing.
• Act on age before cycle time. Work item age flags trouble while the item can still be helped; cycle time only describes items already done.
• Keep definitions fixed. Changing the start or finish point makes old and new data incomparable, so note any change and restart the baseline.
• Read the cumulative flow diagram for shape. Widening bands point at bottlenecks, as Atlassian's documentation explains, and a flat line for finished work means nothing is being delivered.
• Use metrics to improve the system. Using them to rank individuals invites gaming and hides the problems you need to see.

Common Mistakes

• Mixing lead time and cycle time: Teams quote one number while stakeholders hear another. Write down what each term means on your board and which points it measures between.
• Reporting only averages: Averages look stable while a minority of items take far longer. Show percentiles or the full scatterplot.
• Ignoring items in progress: Cycle time only covers finished work, so a stuck item is invisible until it finally closes. Track work item age daily.
• Counting the backlog as WIP: If options sit inside the measured span, WIP and cycle time are inflated. Start the clock at the commitment point.
• Collecting data nobody discusses: Charts that are never reviewed change nothing. Bring them to a regular review and leave with an experiment.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Kanban

Related Skills

• Setting WIP Limits
• Running Kanban Cadences
• Managing Projects with Kanban
• Designing Kanban Boards
• Creating Kanban Pull Policies
• Comparing Kanban and Scrum
• Choosing Kanban Software

Sources

• The Kanban Guide
• The Official Guide to The Kanban Method (PDF)
• John D. C. Little: Little's Law as Viewed on Its 50th Anniversary
• Atlassian Support: View and understand the cumulative flow diagram
• Daniel S. Vacanti: Actionable Agile Metrics for Predictability

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.