Kanban

Managing the flow of work: visualizing work, limiting work in progress, flow metrics such as cycle time and throughput, Little's Law, and using Kanban with Scrum.

What Kanban is

The word comes from Japanese and means roughly "signboard" or "visual card". At Toyota, as part of the Toyota Production System (see Lean Thinking), kanban cards traveled with parts: when a station used up a container of parts, the card went back upstream as a signal to make more. Nothing was produced without a signal, which kept inventory low and made problems visible quickly. That is a pull system: work is pulled in when there is capacity, not pushed in because it exists.

From the mid-2000s, people applied the same idea to knowledge work such as software development, IT operations and service desks, where the "inventory" is invisible: half-finished features, tickets waiting for someone, changes waiting for approval. Kanban in this sense is a way of managing such work by making it visible, limiting how much is in progress at once, and improving the flow based on measurements. Unlike Scrum, it does not prescribe roles, events or fixed-length iterations: you start from the process you have.

The Kanban Guide and the Kanban Method

"Kanban" is used by two communities with somewhat different emphasis. Knowing which one a colleague means saves confusion.

The Kanban Guide: three practices

The Kanban Guide is a short, free document maintained by Daniel Vacanti and John Coleman with other contributors; the current version is v2025.5 (May 2025), published under CC BY-SA 4.0. It defines Kanban as "a strategy for optimizing the flow of value through a process" and asks for three practices:

  1. Defining and visualizing the workflow. The team agrees a Definition of Workflow (DoW): among other things, what a work item is, where work starts and finishes, the states in between, how work in progress is controlled, and a service level expectation. The board is how that definition becomes visible.
  2. Actively managing items in the workflow. Keep WIP under control, make sure items do not get stuck or age unnoticed, and finish work before starting new work.
  3. Improving the workflow. Use the flow metrics to find where work waits and change the DoW, the policies or the limits accordingly.

The guide names four flow metrics that every Kanban system tracks: WIP, throughput, work item age and cycle time. They are explained below. 

Work item:      a Product Backlog item or a bug on the customer portal
Started:        when a Developer pulls it from Ready into Build
Finished:       when it meets the Definition of Done and is deployed
States:         Ready → Build → Review & test → Done
WIP limits:     Build 3, Review & test 2 (Ready: at most 4 waiting)
Policy:         a bug that blocks payments may skip the queue (one at a time)
SLE:            85% of items finish within 9 days of starting

The Kanban Method

The Kanban Method, developed by David J. Anderson from around 2005 and taught by Kanban University, is broader. Besides practices such as visualizing, limiting WIP, managing flow, making policies explicit, feedback loops and evolutionary improvement, it emphasizes change management: start with what you do now, pursue evolutionary rather than revolutionary change, and encourage leadership at every level. It also adds cadences (regular review meetings) and a maturity model. The two communities parted ways around 2020; in daily use the boards look the same, but the Method puts more weight on organizational change and the Guide on a small set of flow practices and metrics.

The Kanban board

A Kanban board shows the workflow as columns (one per state) and each work item as a card that moves from left to right. What makes it a Kanban board rather than a simple task board is that it shows the rules of the flow as well: WIP limits per column, where an item counts as started and finished, and how long each item has been in progress. Here is the Portal team's board on a Monday morning.

A Kanban board with four columns. Ready, limit 4, holds three cards: PBI-121, PBI-122 and PBI-123. Build, limit 3, holds three cards and is full: PBI-117 aged 6 days, PBI-118 aged 3 days and PBI-119 aged 1 day. Review and test, limit 2, holds one card: PBI-116 aged 8 days. Done holds PBI-114 and PBI-115. A note says Build is at its limit, so the next step is to help finish PBI-116 rather than start new work. Ready limit 4 · 3 waiting Build limit 3 · full Review & test limit 2 · 1 item Done no limit PBI-121 PBI-122 PBI-123 PBI-117 6 d PBI-118 3 d PBI-119 1 d PBI-116 8 d PBI-114 PBI-115 Build is full: help finish PBI-116 before starting new work.
The Portal team's board. Numbers on the cards are work item age in days. The highlighted card is the oldest item in progress and the first one to talk about.

The Ready column holds items that are refined and may be started; they do not count as work in progress yet, because nobody has started them. The Done column has no limit: finished work is the goal. Teams often split a column into "doing" and "done" (for example Build: doing / ready for review) so that waiting time inside a state is visible.

Work in progress and WIP limits

Work in progress (WIP) is the number of items that have been started but not yet finished. A WIP limit is an explicit upper bound on that number, for a column, a group of columns or the whole board. When a column is at its limit, nobody pulls new work into it; instead people help to finish what is already there.

Limiting WIP feels slower at first, but it speeds delivery up:

  • Less waiting. With ten items in progress and capacity for three, seven are always waiting somewhere. Every waiting day is added to their cycle time.
  • Less task switching. People who juggle five items lose time getting back into each one and make more mistakes.
  • Bottlenecks become visible. When Review & test is full and Build is waiting, the team sees where to help instead of piling up more half-finished work.
  • Faster feedback. Finished work can be used and learned from; unfinished work only carries risk.

The slogan "stop starting, start finishing" sums it up. There is no formula for the right limit: start near the current number of people per column, watch the metrics, and lower the limit until work starts waiting for people instead of people waiting for work.

Flow metrics

The Kanban Guide asks for four metrics, all of which you can derive from two dates per item: when it started and when it finished. Besides WIP (above), these are:

Cycle time

Cycle time is the time an item took from start to finish, as defined in the Definition of Workflow. It is the metric customers feel: how long they wait once work has begun. A common convention counts both the start and the finish day, so an item started and finished on the same day has a cycle time of one day.

Work item age

Work item age is the time that has passed since an unfinished item started. Cycle time only exists after the fact; age is the early warning. An item that is already older than most items take in total needs attention now, not at the retrospective.

Throughput

Throughput, in the flow sense, is the number of items finished per unit of time: per day, per week or per Sprint. It counts items, not effort, and it is the input for forecasts such as "how many items by the end of the month?" (see Estimation and Forecasting). In networking, throughput means data transferred per second; it is the same idea of "how much gets through", applied to work items.

The metrics from a small dataset

Ten items from the Portal team's board in September 2026: eight finished, two still in progress. The example calculates cycle times, throughput per week and the age of the unfinished items, and then checks Little's Law (explained in the next section) over the period in which the finished items ran. 

from datetime import date, timedelta

# Portal team items: (id, started, finished or None if still in progress)
items = [
    ("PBI-101", date(2026, 9, 1), date(2026, 9, 4)),
    ("PBI-102", date(2026, 9, 1), date(2026, 9, 9)),
    ("PBI-103", date(2026, 9, 3), date(2026, 9, 7)),
    ("PBI-104", date(2026, 9, 7), date(2026, 9, 10)),
    ("PBI-105", date(2026, 9, 8), date(2026, 9, 16)),
    ("PBI-106", date(2026, 9, 10), date(2026, 9, 14)),
    ("PBI-107", date(2026, 9, 14), date(2026, 9, 18)),
    ("PBI-108", date(2026, 9, 15), date(2026, 9, 18)),
    ("PBI-109", date(2026, 9, 21), None),
    ("PBI-110", date(2026, 9, 24), None),
]
today = date(2026, 9, 28)

def days(start, end):
    # Count both the first and the last day: started and finished
    # on the same day is a cycle time of 1 day.
    return (end - start).days + 1

finished = [(i, s, f) for i, s, f in items if f is not None]
cycle_times = [days(s, f) for _, s, f in finished]
print("Cycle times (days):", cycle_times)
print(f"Average cycle time: {sum(cycle_times) / len(cycle_times):.1f} days")

per_week = {}
for _, _, f in finished:
    week = f.isocalendar().week
    per_week[week] = per_week.get(week, 0) + 1
print("Flow throughput per ISO week:", per_week)

print("\nWork item age of unfinished items on", today)
for item_id, start, finish in items:
    if finish is None:
        print(f"  {item_id}: {days(start, today)} days")

# Little's Law check over the period in which the finished items ran.
# No other item was in progress then, so WIP is complete.
first = min(s for _, s, _ in finished)
last = max(f for _, _, f in finished)
period = days(first, last)
wip_per_day = []
for n in range(period):
    day = first + timedelta(days=n)
    wip_per_day.append(sum(1 for _, s, f in finished if s <= day <= f))
avg_wip = sum(wip_per_day) / period
throughput = len(finished) / period

print(f"\nPeriod: {first} to {last} ({period} days)")
print(f"Average WIP:        {avg_wip:.2f} items")
print(f"Flow throughput:    {throughput:.3f} items per day")
print(f"WIP / throughput:   {avg_wip / throughput:.1f} days")
Cycle times (days): [4, 9, 5, 4, 9, 5, 5, 4]
Average cycle time: 5.6 days
Flow throughput per ISO week: {36: 1, 37: 3, 38: 4}

Work item age of unfinished items on 2026-09-28
  PBI-109: 8 days
  PBI-110: 5 days

Period: 2026-09-01 to 2026-09-18 (18 days)
Average WIP:        2.50 items
Flow throughput:    0.444 items per day
WIP / throughput:   5.6 days

The two ages say something the averages cannot: PBI-109 is already 8 days old, older than all but two finished items took in total. That is the item to discuss first today.

Little's Law

Little's Law, from queueing theory (John Little, 1961), says that in a stable system the average number of items in the system equals the average arrival rate times the average time an item spends in it. Rewritten for flow: 

average cycle time = average WIP ÷ average throughput

In the example: 2.50 items in progress on average, 0.444 items finished per day, so 2.50 ÷ 0.444 = 5.6 days, exactly the average cycle time. It matches exactly because every item in the period started and finished inside it, so the system was empty at the start and the end. In real data it will be close, not exact.

The practical lesson is the one the Kanban Guide for Scrum Teams (2021) draws: if throughput stays the same, more WIP means longer cycle times. If items take too long, the first thing to try is lowering WIP, not working harder. The relationship only holds when its assumptions are roughly met:

  • on average, work arrives as fast as it leaves;
  • all work that starts eventually finishes (or is counted when it is abandoned);
  • WIP is about the same at the start and end of the period;
  • the average age of the WIP is neither growing nor shrinking;
  • the same units are used everywhere (days and items per day).

The cumulative flow diagram

A cumulative flow diagram (CFD) plots, for each day, how many items have reached each state so far. Every state becomes a band. Because the lines only go up, the picture is easy to read once you know what to look for:

A cumulative flow diagram over ten days. From bottom to top the bands are Done, Review and test, Build and Ready. All lines rise steadily. On day 7, the vertical distance between the top of the Build band and the top of the Done band is 5 items, labeled work in progress. A horizontal line from day 5 to day 10 at the level of 6 items shows the approximate cycle time. WIP = 5 ≈ cycle time Done Review & test Build Ready 0 4 8 12 1 4 7 10 Day Items (cumulative)
A CFD for the Portal team. The vertical distance between the started line (top of Build) and the Done line is the WIP on that day; the horizontal distance is roughly the cycle time.
  • Parallel bands: work arrives and leaves at the same rate; the system is stable.
  • A band that widens: work piles up in that state, usually a bottleneck right after it.
  • A flat Done line: nothing is being finished, even if everyone is busy.
  • The top line rising faster than the rest: more work is being accepted than the team can finish.

The Scrum Guide mentions cumulative flows, alongside burn-downs and burn-ups, as one of several optional practices for forecasting progress.

Service level expectations

A service level expectation (SLE) is a forecast of how long a single item should take from start to finish, with a probability: "85% of our items finish within 9 days of starting". It is part of the Definition of Workflow and is based on the team's own past cycle times, not on estimates. Unlike a service level agreement, it is not a contract with penalties but a team's expectation that helps it notice early when an item is in trouble.

The 85% value is the 85th percentile of recent cycle times. The example computes several percentiles from the Portal team's last 20 finished items and compares the work item age of today's unfinished items with them. 

import math

# Cycle times (days) of the portal team's last 20 finished items
cycle_times = [4, 9, 5, 4, 9, 5, 5, 4, 3, 6, 7, 2, 8, 6, 14, 5, 7, 4, 6, 10]

def percentile(values, pct):
    # Nearest-rank method: the smallest value that at least pct% of
    # the items are less than or equal to.
    ordered = sorted(values)
    rank = math.ceil(pct / 100 * len(ordered))
    return ordered[rank - 1]

for pct in (50, 70, 85, 95):
    print(f"{pct}% of items finished within {percentile(cycle_times, pct)} days")

sle_days = percentile(cycle_times, 85)
print(f"\nService level expectation: 85% of items within {sle_days} days")

# Unfinished items and their work item age today
ages = {"PBI-109": 8, "PBI-110": 5, "PBI-111": 2}
for item_id, age in ages.items():
    if age >= sle_days:
        status = "past the SLE: swarm or split it"
    elif age >= percentile(cycle_times, 70):
        status = "aging: discuss at the Daily Scrum"
    else:
        status = "on track"
    print(f"{item_id}: age {age} days, {status}")
50% of items finished within 5 days
70% of items finished within 7 days
85% of items finished within 9 days
95% of items finished within 10 days

Service level expectation: 85% of items within 9 days
PBI-109: age 8 days, aging: discuss at the Daily Scrum
PBI-110: age 5 days, on track
PBI-111: age 2 days, on track

Percentiles are better than an average here because cycle times are skewed: most items are quick and a few take much longer. The average (6.2 days for these 20 items) would promise customers too much.

Kanban with Scrum

Kanban and Scrum are not competitors. The Kanban Guide for Scrum Teams, published in January 2021 by Scrum.org, Daniel Vacanti and Yuval Yeret, describes how a Scrum Team can add Kanban practices without changing Scrum itself. The Sprint, the accountabilities and the events stay; the team adds a Definition of Workflow, WIP limits and the four flow metrics:

  • Sprint Planning can use historical throughput as an aid to judge how much work fits in the Sprint.
  • The Daily Scrum focuses on flow: which items are aging, what is blocked, and what the team can finish today.
  • The Sprint Retrospective can inspect the flow metrics and change the Definition of Workflow.
  • Flow does not stop at the Sprint boundary. Items can start and finish whenever capacity allows, and the Definition of Workflow may span beyond a single Sprint.

The Scrum events themselves are on Scrum Events. Kanban without Scrum is common in operations teams, where most work arrives unannounced; see Agile in IT Operations.