A kanban board shows where work is, but metrics show how reliably it moves. This guide explains kanban cycle time, lead time, throughput, flow efficiency, percentiles, and cumulative flow diagrams, then turns them into a practical review checklist for software and operations teams.
Overview
Metrics are most useful when they help a team improve its workflow rather than judge individual performance. A project tracking board can provide the raw events: when a task enters a queue, when active work begins, when it is blocked, and when it is completed. The team can then use those events to identify delays, adjust work-in-progress limits, and make more realistic delivery forecasts.
Start with a small set of measures. For most teams, cycle time, throughput, and a view of work in progress provide enough information for an initial review. Add lead time and flow efficiency when you need to understand waiting before work starts or the proportion of time spent actively progressing. Percentiles are generally more informative than a simple average because a few unusually long items can distort the average.
| Metric | Definition | Formula or calculation | Useful question |
|---|---|---|---|
| Cycle time | Elapsed time from active work starting to completion | Completion date minus start date | How long does work take once the team begins it? |
| Lead time | Elapsed time from a request entering the workflow to completion | Completion date minus request date | How long does a requester wait from demand to delivery? |
| Throughput | Number of completed items in a defined period | Completed items ÷ period | How much work is the system completing? |
| Flow efficiency | Share of elapsed time spent actively progressing | Active time ÷ total elapsed time × 100 | How much time is spent waiting or blocked? |
| Work in progress | Items started but not yet completed | Count of unfinished items at a point in time | Is too much work competing for attention? |
For example, suppose five completed tasks have cycle times of 2, 3, 4, 6, and 10 working days. Their average cycle time is 5 working days, but the middle value is 4 days. The 10-day item deserves inspection: it may have been blocked, unusually large, or affected by a workflow change. Reporting both the average and a percentile or median gives a more useful picture than presenting one number without context.
A cumulative flow diagram adds a visual view. It displays the number of items in each workflow state over time. A widening band usually indicates that work is accumulating in that state. For example, if the testing band expands while development remains stable, testing may be the current constraint. The diagram does not explain the cause by itself, but it directs the team toward a focused conversation.
Checklist by scenario
When setting up metrics on a new kanban board
- Define the start and finish points for cycle time. A practical definition might be from “In Progress” to “Done,” but use the states that reflect your actual workflow.
- Define lead time separately. Decide whether it begins when a request is submitted, approved, added to the backlog, or moved into a ready queue.
- Use consistent completion criteria. A task should not count as complete simply because it left one team’s column if another required delivery step remains.
- Record blocked time where possible. A blocked label, reason, or status makes waiting visible without changing the original start and finish dates.
- Choose a reporting period that contains enough completed work to reveal a pattern. Avoid drawing conclusions from one or two items.
When cycle time is increasing
- Compare the current median or selected percentile with earlier periods rather than relying only on the overall average.
- Inspect the cumulative flow diagram for a growing band or a state where items remain for longer.
- Check whether work items became larger or more complex. A change in item size can explain a metric change without indicating a process failure.
- Review blocked items by reason: dependency, approval, environment, unclear requirements, or competing priority.
- Check work-in-progress levels. Too many active items can increase context switching and delay finishing.
When throughput is lower than expected
- Confirm that the definition of “done” and the reporting window have not changed.
- Separate planned work, support requests, defects, and emergencies if they follow different paths through the board.
- Look for aging items that remain open and consume attention without reaching completion.
- Compare throughput with work-item size. Fewer larger items may represent a similar amount of effort as more smaller items.
- Use the result to review capacity and prioritization, not to assign individual quotas.
When preparing a monthly team review
- Export or open the relevant board history for completed and unfinished items.
- Clean the data using the checks below.
- Review cycle time, lead time, throughput, work in progress, and the cumulative flow diagram together.
- Identify one or two bottlenecks supported by examples from the workflow.
- Choose a small process experiment, such as lowering a WIP limit, clarifying a handoff, or adding an automation rule.
- Record the expected signal and review it during the next delivery cycle.
What to double-check
Reliable kanban metrics depend on reliable board data. Before interpreting a chart or dashboard, run this data-cleaning checklist:
- Dates: Confirm that timestamps use the same time zone and that working-day or calendar-day calculations are applied consistently.
- State changes: Check whether moving an item backward, reopening it, or splitting it creates a new start date. Document the rule and apply it consistently.
- Subtasks: Decide whether metrics apply to parent tasks, subtasks, or both. Counting both can inflate throughput.
- Pauses: Determine whether approved pauses, holidays, and external waiting periods remain in elapsed time. Do not remove them without recording the decision.
- Scope: Exclude test cards, duplicates, cancelled requests, and administrative items when they do not represent comparable delivery work.
- Item size: Note significant changes in task size, because throughput and cycle time are easier to compare when work units are reasonably consistent.
- Workflow changes: Mark the date a column, policy, WIP limit, or automation rule changed. A trend break may reflect the new process rather than team performance.
Use flow efficiency carefully. If a task spends two days in active development and eight days waiting for review, its flow efficiency is 20 percent: 2 ÷ 10 × 100. That result is a prompt to examine the review queue, not proof that the eight days were wasteful. Some waiting is required for approvals, external dependencies, or scheduled releases. The useful question is whether the waiting is intentional, visible, and manageable.
Similarly, throughput should not be read in isolation. A team can increase its count of completed items by splitting work into smaller cards, while the customer-facing outcome remains unchanged. Compare throughput with delivery scope, cycle time, defects, and the definition of done.
Common mistakes
- Using averages alone: A mean can hide a long tail of delayed work. Include a median or selected percentile and inspect outliers.
- Measuring individual speed: Individual rankings encourage local optimization, shortcuts, and avoidance of complex work. Use metrics to improve the system and team policies.
- Changing definitions midstream: If cycle time changes from “first development activity” to “ready for release,” the historical comparison is no longer direct. Mark the change or recalculate earlier data.
- Ignoring unfinished work: Throughput counts completed items, so it can look stable while the backlog of aging work grows. Review open-item age and WIP as well.
- Tracking too many measures: A dashboard crowded with charts can reduce attention to the constraint that needs action. Start with a few measures tied to a decision.
- Treating the board as a diary: A kanban board should reflect the workflow in a timely way. If cards are updated only at the end of the week, timestamps and bottleneck signals become less trustworthy.
A kanban board template or project workflow management tool can make these reviews easier when its columns, timestamps, history, filters, and reporting rules match the team’s process. Automation can help apply labels or notify owners, but automated transitions should be reviewed so they do not create misleading start or finish events.
When to revisit
Revisit these metrics before seasonal planning cycles, after a major workflow or tool change, and whenever delivery complaints conflict with the dashboard. Review them after changing WIP limits, team responsibilities, release policies, approval steps, or the definition of done. Also return to the checklist when a new work type, such as incidents or operational requests, is added to an existing board.
For the next review, reserve a short, focused session and complete these actions:
- Write down the current definitions of cycle time, lead time, throughput, and done.
- Check the last reporting period for missing dates, duplicate cards, reopened items, and unusual workflow changes.
- Compare the current median or percentile with at least one earlier period.
- Open the cumulative flow diagram and identify the widest or fastest-growing band.
- Select one bottleneck to investigate and one small change to test.
- Set a date for the next review and record what evidence would show that the change helped.
Used this way, kanban metrics turn a task board into a feedback system. They help teams see where work waits, make constraints discussable, and improve delivery without reducing complex work to a single score.
