Skip to content

Lesson 3 — Kanban and Work-in-Progress Limits

At a glance

  • Module: 04 — Agile, Scrum & Lean Delivery
  • Level: Intermediate
  • Estimated time: 35 minutes
  • Example project: the hospital appointment system

Learning objectives

By the end of this lesson you should be able to:

  1. Explain Lean thinking and how Kanban applies it to software work.
  2. Visualise a workflow and define explicit policies for it.
  3. Apply a work-in-progress limit and explain why it improves delivery time.
  4. Use flow measures — work in progress, cycle time, and throughput — to diagnose a bottleneck.

Prerequisites

Introduction

Scrum organises work into fixed-length Sprints. Kanban takes a different route: it does not change how you work, it makes your existing flow visible and limits how much is in flight at once.

The starting point is a counter-intuitive claim: starting more work makes you finish less. This lesson explains why that is true, how a work-in-progress limit exploits it, and how to tell whether your flow is actually healthy.

1. Lean thinking

Lean is a set of principles, originally from manufacturing, that focus on delivering value while removing waste. In software, the wastes that matter most are:

Waste Software example
Partially finished work A feature 90% done for three months
Waiting Work blocked on a review or an environment
Rework Building the wrong thing, or rebuilding after a defect
Handover overhead Work passing through many people who must re-understand it

The largest of these is usually partially finished work. It has consumed effort, delivered nothing, and is likely to become obsolete before it is finished.

2. Visualise the work and make policies explicit

A Kanban board shows the stages work passes through — for example: Ready → In progress → Review → Test → Done. Two things make it more than a task list:

  • Explicit policies. What does "Ready" mean? What has to be true before work enters "Review"? Written policies prevent the board from becoming decorative.
  • Pull, not push. Work moves forward when there is capacity downstream, not when someone finishes upstream. Otherwise the board simply proves you have too much in progress.

3. Work-in-progress limits

A WIP limit caps how many items may be in a stage at once. It forces a decision: when the limit is reached, you must finish something rather than start something.

Why it works is captured by Little's Law, a result from queueing theory:

Average work in progress = throughput × average cycle time

Rearranged: cycle time = WIP ÷ throughput. If throughput is fixed, reducing work in progress reduces the time each item takes. That is the whole mechanism.

Hospital appointment system (illustrative)

A team of three supports the hospital appointment system plus several other systems. Twelve requests are "in progress" at once. Each developer switches between four or five items, so nothing finishes. When the team limits work in progress to one item per developer plus one waiting for review, items start finishing — not because anyone works faster, but because work stops queueing behind work.

4. Measuring flow

Little's Law gives three measures worth tracking, all computed from the board:

Measure Meaning Reveals
Work in progress Items started but not finished Overload; use it to enforce the limit
Cycle time Time from starting an item to finishing it Delivery predictability
Throughput Items finished per period Capacity

If cycle time is rising while throughput is flat, work in progress has grown. The remedy is not more pressure; it is finishing something.

Key terms

Term Meaning
Lean Principles emphasising value delivery, waste removal, and flow
Kanban A flow-based method using a visible board and WIP limits
Work in progress (WIP) Items started but not yet finished
WIP limit A cap on how many items may be in progress in a stage
Cycle time Elapsed time from starting an item to finishing it
Throughput Number of items completed in a period
Pull system Work moves forward when downstream capacity allows
Little's Law Average WIP equals throughput multiplied by average cycle time

Worked example

Task: diagnose and improve a team's flow. All numbers are invented for illustration.

Step 1 — Measure the current state. A team has 12 items in progress, finishes 6 items per week, and each item takes about 3 weeks. Check the arithmetic: 12 WIP against 6 per week × 3 weeks = 18. The numbers do not agree, so at least one measurement is wrong — most likely "in progress" is being counted loosely.

Step 2 — Recount honestly. Items that are blocked, waiting, or parked in a review queue are still in progress. The true figure is closer to 18. The measurement is now consistent, which already tells you the team is carrying far more than it can finish.

Step 3 — Set a limit. Cap work in progress at 3 per developer (a team of four, so 12), and cap the review column at 2. The limits are a decision, and the team should be the one to make it.

Step 4 — Predict the effect. If throughput stays at 6 per week and WIP drops to 12, Little's Law gives cycle time = 12 ÷ 6 = 2 weeks, down from 3. Note the caveat: throughput may rise too, which would improve it further — but the honest statement is a prediction, not a promise.

Step 5 — Watch the bottleneck move. The limit that is constantly hit is the real constraint. If review is always at its limit, the problem is review capacity, not developer effort.

Step 6 — State what you would change and why. Adding a reviewer, or clarifying the review policy so fewer items need review, addresses the constraint. Asking developers to work harder does not, because the constraint is not where the pressure is being applied.

Common misconceptions

“A Kanban board is a to-do list in columns”

A board without explicit policies and limits changes nothing. The limits are what force finishing over starting.

“WIP limits make us slower because we start less”

They reduce the time each item takes, and they reduce partially finished work — which is the most expensive form of waste. Less started, more finished, sooner.

“100% utilisation is the goal”

Fully utilised people have no slack, so every small delay propagates and cycle times grow. Flow improves with deliberate slack, not without it.

Practical activity

Map and limit a workflow. Choose a real workflow — a group coursework queue, a support inbox, or an example project's delivery process.

  1. Draw the board stages as a Mermaid diagram.
  2. Write an explicit policy for entering each stage (one sentence each).
  3. Measure or estimate current WIP, throughput, and cycle time.
  4. Set a WIP limit, and predict the new cycle time using Little's Law.
  5. Name the stage you expect to become the bottleneck.

What "good" looks like: a prediction you can check later, and a bottleneck hypothesis. A board with no limits has not done the exercise.

Self-assessment

  1. Using Little's Law, what happens to cycle time if you double work in progress and throughput does not change?
  2. Why is partially finished work described as the largest form of waste in software?

  3. Your review column is permanently at its WIP limit. What does that tell you, and what would you not do?

  4. Apply it — student portal maintenance team. In a two-week window the five-person team starts 14 items and finishes 5; nine items are still open, and the team says work is going well because everyone is busy. The average item is taking about four weeks end to end.

    Hint: A strong answer uses Little's Law with the numbers, and names one policy change that follows from it.

Show answers
  1. Cycle time doubles. Cycle time = WIP ÷ throughput, so if WIP doubles and throughput is flat, each item takes twice as long. This is the arithmetic behind why starting more work finishes less.
  2. Because it has consumed effort, delivered no value, and continues to decay — requirements move, code drifts from the mainline, and the knowledge needed to finish it fades. Unlike rework, which at least produces something, unfinished work produces nothing while consuming capacity.
  3. It tells you the constraint is review capacity, not development capacity. You would not respond by asking developers to work faster, because the queue they are feeding is the problem. The useful responses are to increase review capacity, reduce the amount needing review, or change the review policy.
  4. Throughput is 5 items per two weeks = 2.5 items per week, and work in progress is 9 items, so Little's Law gives an expected cycle time of 9 ÷ 2.5 ≈ 3.6 weeks — which matches the four weeks being observed. The arithmetic points at WIP, not effort: starting more work cannot raise throughput here, it only makes every item wait longer. The policy change that follows is to set an explicit WIP limit below the current level — for example five items in the active columns, one per person — and require an item to be finished before another is pulled. Then find where items queue: that column is the constraint, and it is the only place worth improving.

Summary

  • Lean targets waste; in software the largest waste is usually partially finished work.
  • Kanban makes flow visible and constrains it with explicit policies and WIP limits.
  • Little's Law explains the mechanism: with throughput fixed, less work in progress means shorter cycle times.
  • Flow measures reveal the real constraint, which is rarely where the pressure is being applied.

Further learning

Next

You have completed Module 04. Continue to Module 05 — Scope & Requirements Management.