Kanban: Boards, WIP Limits and Flow Metrics | Free Project Management Course

What you'll learn

Design a Kanban board that mirrors how work really flows through your team.
Set work-in-progress (WIP) limits and explain why they make work finish faster.
Measure cycle time, throughput and WIP, and connect them with Little's Law.
Read a cumulative flow diagram to spot bottlenecks.
Make delivery promises with percentiles instead of averages.

Kanban is a method for managing a continuous flow of work by making it visible on a board, limiting how much is in progress at once, and measuring how long work takes to get through. Unlike Scrum, it has no sprints and no required roles: you start with your current process and improve it step by step. It's ideal for teams whose work arrives as a steady stream of requests, like support, operations, marketing or design. In this lesson, a creative team at a Nashville hospital network uses it to cut its turnaround time in half without hiring anyone.

WIP ÷ throughput= average cycle time (Little's Law). Less work in progress means faster delivery.

3 → 1.5weeks of average cycle time in this lesson's example, with the same team

85thpercentile: the cycle time to use when someone asks "when will mine be done?"

Visualize the work
Limit WIP
Measure flow
Read the CFD
Forecast with percentiles

The problem: everything is "in progress"

The creative services team at a hospital network in Nashville has six designers. They handle requests from 40 departments: flyers, patient brochures, social graphics, signage. Everyone was busy, yet requesters kept complaining that "simple" jobs took three weeks. When the team counted, about 30 requests were in progress at any time: five per designer. Each person was switching between jobs all day, and most jobs spent most of their life waiting.

Step 1: visualize the workflow

A Kanban board has one column per stage that work actually goes through, and one card per work item. Start with your real process, not an ideal one. The team's board:

Backlog	Ready (limit 6)	Designing (limit 6)	Review (limit 3)	Done
New requests, not yet committed	Clarified, with brief and assets	A designer is working on it	Requester or compliance is reviewing	Approved and delivered
12 cards	5 cards	6 cards	3 cards	Moved to the archive weekly

Make work visible

Every request is a card. If it isn't on the board, nobody works on it.

Tip: color cards by type (print, digital, urgent) to see the mix.

Limit WIP

Each active column has a maximum number of cards. When it's full, nobody pulls more in.

Tip: a common starting point is about one item per person in the work column.

Pull, don't push

People pull the next card when they have capacity, starting from the right side of the board.

Motto: stop starting, start finishing.

Make policies explicit

Write down what "Ready" and "Done" mean, and how urgent items are handled.

Example: one "expedite" lane, with a limit of one card.

Step 2: set WIP limits

WIP limits feel backward at first: how can doing less at once make you faster? Because most delay is waiting, not working. When a designer juggles five jobs, each job waits while the other four get attention, and every switch costs time to get back into context. With a limit, a stuck card can't be ignored: when Review is full, designers can't start new work, so they help clear the review queue. The limit turns hidden bottlenecks into visible problems that people solve.

1. The Review column has a WIP limit of 3 and already holds 3 cards. A designer just finished a design. What should happen?

Help clear Review (chase approvals, fix feedback) before pulling new work
Move the card into Review anyway; limits are guidelines
Start a new design from Ready to stay busy

A full column is a signal to swarm on the bottleneck. Starting new work would raise WIP and slow everything down, which is exactly what the limit is there to prevent.

Step 3: measure flow with Little's Law

Three metrics describe how work flows:

WIP: the number of items started but not finished.
Throughput: the number of items finished per unit of time (per week, for example).
Cycle time: how long an item takes from start (pulled into Ready) to finish (Done). Lead time is the same idea measured from the moment the request arrives.

On average, over a stable period, they're linked by Little's Law:

Average cycle time = Average WIP ÷ Average throughput

Before WIP limits:  30 items ÷ 10 items per week = 3 weeks
After WIP limits:   15 items ÷ 10 items per week = 1.5 weeks

The team didn't work harder or hire anyone. Throughput stayed at about 10 requests a week. Cutting WIP from about 30 to 15 (the sum of the Ready, Designing and Review limits) cut the average wait in half.

2. A team has an average of 24 items in progress and finishes 8 items a week. What's the average cycle time?

2 weeks
3 weeks
8 weeks

Little's Law: 24 ÷ 8 = 3 weeks. To bring it down to 2 weeks without increasing throughput, average WIP would have to drop to 16.

Step 4: read the cumulative flow diagram

A cumulative flow diagram (CFD) stacks, week by week, how many items have reached each stage. The vertical thickness of a band is the number of items in that stage; the slope of the bottom band is throughput.

Before week 4 the orange band keeps widening: work is started faster than it's finished. After WIP limits, the band narrows and then runs parallel, the sign of a stable, predictable flow.

How to read any CFD in ten seconds:

A widening band means items pile up in that stage: a bottleneck, and growing cycle times.
Parallel bands mean a stable flow: work leaves at about the rate it enters.
A flat bottom band means nothing is being finished. Find out why today.

3. On a CFD, the "Review" band has been getting wider for three weeks. What does it most likely mean?

The team is finishing more work than ever
New requests have stopped arriving
Work is piling up in review: a bottleneck that's increasing cycle time

A widening band means items enter that stage faster than they leave it. Typical fixes: a WIP limit on Review, faster approval rules, or designers helping chase approvals.

Step 5: forecast with percentiles, not averages

When a department head asks "when will my brochure be done?", the average is a poor answer: half of all items take longer than the median. Look at the cycle times (in workdays) of the team's last 20 finished requests:

2, 3, 3, 4, 4, 4, 5, 5, 5, 6, 6, 7, 7, 8, 8, 9, 10, 12, 14, 21

Average:          143 ÷ 20 = 7.15 days
Median:           (6 + 6) ÷ 2 = 6 days     → half finish in 6 days or less
85th percentile:  17th of 20 values = 10 days → 17 of 20 finish in 10 days or less

So the team's service level expectation becomes: "85% of requests are done within 10 workdays." It's honest, based on data and easy to check. The one 21-day item deserves a look of its own: it waited two weeks for legal review, a policy problem the team then fixed.

ScrumFixed cadence

Rhythm: Sprints of one month or less
Roles: Product Owner, Scrum Master, Developers
Planning: Commit to a Sprint Goal each sprint
Key metric: Velocity (common practice)

New products

KanbanContinuous flow

Rhythm: Continuous; reviews on a regular schedule
Roles: None required; keep your current ones
Planning: Pull the next item when there's capacity
Key metrics: Cycle time, throughput, WIP

Steady request streams

Many teams combine both ("Scrumban"): sprints for planning and review, with a Kanban board and WIP limits inside the sprint.

4. A team's 85th percentile cycle time is 12 days. What does that mean?

Every item takes exactly 12 days
The average item takes 12 days
About 85% of items finish in 12 days or less

A percentile tells you the share of items finished within a given time. It's a safer promise than the average, because most items (not just half) meet it.

Common Kanban mistakes

A board with no WIP limits.

Without limits it's just a to-do list on a wall. Add them, then tune them.

Designing the board around an ideal process.

Map how work really flows today, including the waiting stages.

Treating every request as urgent.

One expedite lane with a limit of one; everything else waits its turn.

Promising dates from the average.

Use the 85th percentile, and keep collecting data.

Practice exercise

An IT help desk at a property management company in Phoenix averages 36 open requests and closes about 12 a week. The last 10 closed requests took 1, 2, 2, 3, 3, 4, 5, 6, 8 and 15 workdays.

(a) What's the average cycle time according to Little's Law? (b) The manager wants 1.5 weeks without hiring. What average WIP would that require? (c) Calculate the median and the 85th percentile of the 10 cycle times (use the nearest-rank method: the value at position 0.85 × n, rounded up).

See solution

(a) 36 ÷ 12 = 3 weeks
(b) WIP = cycle time × throughput = 1.5 × 12 = 18 requests
(c) Median: (3 + 4) ÷ 2 = 3.5 days
    85th percentile: 0.85 × 10 = 8.5 → 9th value = 8 days

The help desk can promise "most requests within 8 workdays" today. Halving WIP from 36 to 18 (for example, a limit of 2 active tickets per technician plus a small Ready column) should bring the average down toward 1.5 weeks. The 15-day outlier should be reviewed: was it waiting on a vendor or a part?

Summary

Kanban visualizes work, limits WIP and manages flow; it starts from your current process.
WIP limits reduce waiting and context switching and expose bottlenecks: stop starting, start finishing.
Little's Law: average cycle time = average WIP ÷ average throughput.
On a CFD, widening bands are bottlenecks and parallel bands are stable flow.
Promise delivery with percentiles (such as the 85th), not averages.

Next lesson: Project Management Tools: Trello, Asana, Jira and Excel. You'll compare the most popular tools and pick the right one with a weighted decision matrix.