---
title: "Kanban and flow metrics | Optimize All Academy"
description: "What Kanban is Kanban is a method for managing and improving the flow of work. Unlike Scrum, it has no fixed iterations or prescribed roles. It starts…"
url: https://optimizeall.com/learn/project-management-leadership-with-ai/kanban-and-flow
updated: 2026-10-05
---

Project Management Leadership with AI · Agile, Scrum, Kanban and hybrid delivery · lesson 13 of 21 · 13 min

# Kanban and flow metrics

## What Kanban is

**Kanban** is a method for managing and improving the flow of work. Unlike Scrum, it has no fixed iterations or prescribed roles. It starts from what you do now and improves incrementally. It suits operations, support, maintenance, marketing, and any work with a continuous stream of varying requests; many product teams use it too.

## Core practices

1. **Visualise the workflow** on a board with columns representing stages (e.g., Backlog → Ready → In progress → Review → Done).
2. **Limit work in progress (WIP)** per column or per person. This is the most important practice.
3. **Manage flow**: watch for blockages, ageing items and bottlenecks.
4. **Make policies explicit**: entry and exit criteria for each column, definitions of done, classes of service.
5. **Implement feedback loops**: regular replenishment, flow reviews and retrospectives.
6. **Improve collaboratively and evolve experimentally.**

## Why limit WIP?

Starting too many things at once slows everything down: context switching wastes time, queues grow and feedback is delayed. **Little's Law** captures the relationship for a stable system:

```
Average cycle time = Average WIP / Average throughput
```

*Illustrative.* A support team has 30 items in progress and completes 10 per week: average cycle time ≈ 3 weeks. If they cap WIP at 15 and throughput stays at 10 per week, average cycle time falls to about 1.5 weeks. Same people, faster delivery, simply by starting less.

## Flow metrics

| Metric | Definition | Why it matters |
|---|---|---|
| **WIP** | Items started but not finished | Leading indicator of delays |
| **Throughput** | Items finished per time period | Delivery rate; basis for forecasts |
| **Cycle time** | Time from start to finish for an item | Customer experience; predictability |
| **Work item age** | Time since an in-progress item started | Early warning of stuck items |

## Forecasting with throughput

Instead of estimating each item, many Kanban teams forecast from historical throughput. For example: "We finish 6–10 items per week (based on the last 12 weeks); 60 items remain, so completion is likely in 6–10 weeks." More advanced teams use Monte Carlo simulation on historical throughput to give probability-based forecasts ("85% likely by 14 June").

## Classes of service

Different work has different urgency and cost of delay:

- **Expedite:** critical issues (limit to one at a time).
- **Fixed date:** regulatory or event deadlines.
- **Standard:** most work, first in first out within priority.
- **Intangible:** important but not urgent (technical debt, improvements).

Making these explicit prevents everything from becoming "urgent".

## Worked example

*Illustrative.* A fictional marketing agency in Dubai handled client requests via email and chat. Everything was urgent, and campaigns were often late. The team introduced a Kanban board with WIP limits (max 3 items per designer in progress), explicit classes of service, and a weekly replenishment meeting with account managers. After two months, average cycle time for standard requests dropped noticeably, fewer items were abandoned midway, and account managers could give clients realistic dates based on throughput data.

## Scrum vs Kanban (and Scrumban)

| | Scrum | Kanban |
|---|---|---|
| Cadence | Fixed Sprints | Continuous flow (with regular reviews) |
| Roles | Defined accountabilities | No prescribed roles |
| Change during cycle | Sprint Goal protected | New items can enter when capacity frees |
| Key metric | Sprint Goal achievement, velocity (for planning) | Cycle time, throughput, WIP |

Many teams combine elements, for example Scrum with WIP limits and flow metrics.

## Common mistakes

- A board with no WIP limits (a to-do list, not Kanban).
- Too many columns that mirror handoffs instead of value flow.
- Ignoring blocked and ageing items.
- Forecasting from wishes rather than throughput data.

## Quick self-check

Count the items currently in progress on your team and the number finished last week. Using Little's Law, what cycle time does that imply? Does it match what customers experience?

## Getting started with Kanban

Start by mapping your current workflow honestly, including waiting states such as "waiting for approval". Put all current work on the board, then set initial WIP limits slightly below current WIP. Expect discomfort: limits expose bottlenecks that were previously hidden. Discuss blocked and ageing items daily, hold a regular replenishment meeting to decide what enters the system next, and review flow metrics every few weeks to adjust limits and policies.

## Hands-on: flow metrics from a board export (Python)

```python
import pandas as pd

df = pd.read_csv("board_export.csv", parse_dates=["started", "finished"])   # id, class, started, finished
done = df.dropna(subset=["finished"]).copy()
done["cycle_days"] = (done["finished"] - done["started"]).dt.days + 1
weekly = done.set_index("finished").resample("W")["id"].count()
days = pd.date_range(df["started"].min(), pd.Timestamp.today().normalize())
wip = [((df["started"] <= d) & (df["finished"].isna() | (df["finished"] > d))).sum() for d in days]
print("Throughput per week (last 8):", weekly.tail(8).tolist())
print("Average WIP (last 30 days):", round(sum(wip[-30:]) / 30, 1))
print("Cycle time 50% / 85%:", done["cycle_days"].quantile([0.5, 0.85]).round(1).tolist())
open_items = df[df["finished"].isna()].assign(age=lambda x: (pd.Timestamp.today() - x["started"]).dt.days)
print(open_items.sort_values("age", ascending=False).head(5)[["id", "age"]])   # oldest items: act on these
```

Most tools (Jira, Trello, Asana and others) can export created/started/resolved dates; column names vary, so map them first.

## Hands-on: a throughput Monte Carlo forecast

```python
import numpy as np

weekly_throughput = [6, 9, 7, 10, 8, 6, 9, 7, 8, 10, 6, 8]    # last 12 weeks (illustrative)
remaining, runs = 60, 20_000
rng = np.random.default_rng(2)
weeks_needed = []
for _ in range(runs):
    done, w = 0, 0
    while done < remaining:
        done += rng.choice(weekly_throughput)
        w += 1
    weeks_needed.append(w)
for p in (50, 85, 95):
    print(f"{p}% likely within {np.percentile(weeks_needed, p):.0f} weeks")
```

## How to measure success

- WIP stays within limits most days; exceptions discussed, not ignored.
- Cycle-time 85th percentile falling and published as a service expectation.
- Forecasts stated as probabilities from throughput data.

## Video lecture: Kanban and flow metrics

Lecture coming soon · 9 chapters · about 8 minutes. Read the full transcript below.

1. Stop starting, start finishing
2. Why it matters
3. The concept: Kanban practices
4. Flow metrics and Little's Law
5. Worked example one: halving WIP
6. Worked example two: the Dubai agency
7. Watch me do it: flow metrics from a board export
8. Forecasting with throughput, and classes of service
9. Common mistakes, recap and try this now

## Lecture transcript

### Stop starting, start finishing

A marketing agency in Dubai, fictional, handled client requests by email and chat. Everything was urgent. Designers juggled a dozen jobs at once. Campaigns were late, and account managers couldn't give clients reliable dates. Nobody was lazy. Everybody was busy. The problem was that too much work had been started and not enough was being finished. In this lecture you'll learn Kanban's core practices: visualising work, limiting work in progress, and managing flow. You'll learn the four flow metrics, why limiting WIP makes delivery faster, how Little's Law explains it, and how to forecast from throughput rather than estimates. By the end, you'll be able to set WIP limits on a board and forecast delivery with data your team already has.

### Why it matters

Why does this matter? Because too much work in progress slows everything down. Each person splits their attention across many items, context switching wastes time, items wait for each other, and nothing finishes. It feels productive, because everyone is busy, but delivery is slow and unpredictable. And for clients and stakeholders, predictability often matters more than raw speed. An agency that reliably delivers standard requests in five days is more valuable than one that sometimes delivers in two and sometimes in twenty. Kanban's focus on flow gives you both: faster delivery on average and far better predictability.

### The concept: Kanban practices

Kanban is a method for managing flow, and its core practices are simple. Visualise the workflow on a board, with columns for each stage the work actually goes through. Limit work in progress, with explicit caps on how many items can be in each stage, or per person. Manage flow: watch how work moves, and act when it stalls. Make policies explicit: what does 'ready' mean, when is something done, how do urgent items get handled? And improve continuously using data. Think of it like a motorway at rush hour. When too many cars enter, everything slows to a crawl. Ramp meters that limit how many cars join keep traffic moving faster for everyone. WIP limits are ramp meters for your work.

### Flow metrics and Little's Law

Four flow metrics. Work in progress: items started but not finished. Throughput: items finished per week. Cycle time: how long an item takes from start to finish. And work item age: how long an in-progress item has been going, which is your early warning of stuck work. These are linked by a relationship known as Little's Law: on average, cycle time equals work in progress divided by throughput, as long as the system is reasonably stable. So here's the key idea. If throughput stays the same and you halve work in progress, average cycle time halves. You don't have to work faster. You just have to start less and finish more. That's why Kanban teams say: stop starting, start finishing.

### Worked example one: halving WIP

Let's work the example from the lesson. A support team has thirty items in progress and finishes ten per week. By Little's Law, average cycle time is thirty divided by ten: about three weeks. Now they cap work in progress at fifteen. If throughput stays at ten per week, which often it does, or even improves because of less context switching, average cycle time becomes fifteen divided by ten: about one and a half weeks. Same people. Same effort. Customers now wait half as long on average. The other fifteen items don't disappear; they wait in a ready queue until there's capacity, which also means the team can reorder them if priorities change, instead of having half-finished work everywhere.

### Worked example two: the Dubai agency

Now the realistic example from the lesson. The fictional Dubai agency introduced a Kanban board. Every request became a card. They set WIP limits: a maximum of three items in progress per designer. They made classes of service explicit: an expedite lane for genuine emergencies, limited to one item at a time; a fixed-date lane for work tied to launches; and a standard lane for everything else. And they held a weekly replenishment meeting with account managers to decide what entered the ready column. After two months, average cycle time for standard requests had dropped noticeably, fewer items were abandoned halfway, and account managers could give clients realistic dates based on throughput data rather than hope. The team felt calmer, too, which matters more than any chart.

### Watch me do it: flow metrics from a board export

Let me show you how to get flow metrics from a board you already use, whether it's Jira, Trello, Asana or a physical board you've been recording. Export two dates per item: when work started and when it finished. Cycle time is the difference in days. Throughput is the count of items finished each week. Work in progress on any day is the count of items started but not yet finished. Then the most useful number of all: cycle-time percentiles. Here, fifty per cent of items finish within four days and eighty-five per cent within eight. That gives you a service level expectation you can share with clients: 'most standard requests are done within eight days'. It's based on data, not promises, and it gets more reliable the longer you track it.

### Forecasting with throughput, and classes of service

Kanban teams often forecast without estimating each item. If you finish six to ten items a week and sixty remain, completion is likely in six to ten weeks. More advanced teams run a Monte Carlo simulation on historical weekly throughput: randomly sample past weeks thousands of times until the remaining items are done, and read off the probability of finishing by each date. That gives statements like: eighty-five per cent likely by the fourteenth of June. It's honest, it's quick and it uses data you already have. Classes of service tell you how to treat different kinds of work: expedite for urgent items, limited in number; fixed date for deadlines; standard for most work, first in, first out; and intangible for important but not urgent work, like improvements, so it isn't forgotten.

### Common mistakes, recap and try this now

The common mistakes: a board without WIP limits, which is just a to-do list; limits that are routinely ignored; everything marked expedite, so nothing is; measuring how busy people are rather than how work flows; and hidden work that never appears on the board. So, to recap. Kanban visualises work, limits work in progress, manages flow with explicit policies and improves with data. Track WIP, throughput, cycle time and work item age. Little's Law tells you that less work in progress means shorter cycle times at the same throughput. And forecast from throughput, ideally with Monte Carlo, rather than from item-by-item estimates. Your try-this-now: set WIP limits on your team's board, or a personal board, for two weeks, and measure throughput and cycle time before and after.

## Key takeaways

- Kanban visualises work, limits WIP, manages flow and makes policies explicit.
- Little's Law: average cycle time = average WIP ÷ average throughput.
- Track WIP, throughput, cycle time and work item age; forecast from throughput.
- Classes of service prevent everything from becoming urgent.

## Try it

Set WIP limits on your team's board (or a personal board) for two weeks, then measure throughput and cycle time before and after.

- [Previous: Scrum essentials](https://optimizeall.com/learn/project-management-leadership-with-ai/scrum-essentials)
- [Next: Hybrid delivery and scaling agile](https://optimizeall.com/learn/project-management-leadership-with-ai/hybrid-and-scaling)
- [All lessons of Project Management Leadership with AI](https://optimizeall.com/learn/project-management-leadership-with-ai)