Kanban

Manage a service through flow: visualise the real workflow, limit work in progress, pull only when capacity exists and improve using explicit policies and evidence.

In one minute

Kanban represents items of value moving through a defined workflow. The team makes the workflow and policies explicit, controls work in progress (WIP), actively manages blocked and ageing items, and reviews flow measures to improve predictability and customer outcomes.

Core flow measures include:

• WIP: items started but not finished;
• throughput: items finished per unit of time;
• work item age: elapsed time for an unfinished item;
• cycle time: elapsed time from start to finish for a completed item.

A service level expectation (SLE) describes a probabilistic expectation for elapsed time based on relevant historical data, for example “85% of standard requests finish within 8 working days.” It is not a guarantee.

Best for: a recurring flow of comparable work where overload, queues and unpredictability matter.
Avoid when: the team cannot define a work item or workflow, the work is a one-off dependency network, or the board would expose sensitive data.

The problem it addresses

Starting work feels productive, so teams open more items than the system can finish. Queues grow invisibly, priorities change without policy and blocked work ages while everyone stays busy. A visual board alone can display the overload without changing it.

Kanban makes demand, capacity, flow and policy discussable. WIP limits create a signal to finish, unblock or renegotiate before pulling more work. The method does not itself define customer value, solve every bottleneck or guarantee continuous delivery.

When to use it

Use Kanban when:

• work arrives continuously or in frequent batches;
• items pass through a repeatable workflow;
• queues, blockers and ageing are operationally important;
• the team can agree explicit entry, exit and pull policies;
• flow data can be collected consistently;
• customers or stakeholders need realistic service expectations;
• improvement can occur without a complete reorganisation.

When not to use it

Do not use it:

• as a decorative task board with no operating policies;
• to schedule a one-time project with complex dependencies—use Critical Path Method;
• before defining the service and work-item boundary;
• to make individual productivity rankings;
• to force unlike work into one misleading cycle-time distribution;
• when WIP limits will be routinely overridden by ungoverned “urgent” work;
• to expose customer, health, employee or security details on a shared board.

Inputs required

Prepare:

• the service, customer, demand types and work-item definition;
• start and finish points and current workflow states;
• entry and exit criteria for each state;
• current WIP, arrival, completion, age and cycle-time data;
• classes of service and expedite authority if genuinely needed;
• capacity, skill, control and privacy constraints;
• ownership and cadence for daily flow and periodic improvement reviews.

Step-by-step process

1. Define the service and work item

State whose need the workflow serves, what unit flows and when it counts as started and finished. Separate materially different item types if they follow different policies or distributions.

2. Visualise the actual workflow

Use states that represent meaningful knowledge or control changes, including waiting and review. Do not redraw an aspirational procedure as current reality.

3. Define explicit policies

For every state specify entry, exit, pull, blocking, rejection, rework and completion rules. Make required evidence and decision authority visible.

4. Establish initial WIP controls

Set limits using observed capacity and risk, then treat them as hypotheses. When a state is full, help finish or unblock work instead of starting more. Govern any exception.

5. Pull work according to capacity

The downstream state selects eligible work when capacity exists. Prioritisation policy should be transparent and connected to customer or risk value.

6. Manage flow every working cycle

Inspect blocked, ageing and policy-violating items. Ask what prevents progress and who can act. Avoid turning the meeting into individual status narration.

7. Measure the flow

Track WIP, throughput, age and cycle time with stable definitions. Use scatterplots, ageing views or cumulative flow to see distributions and trends rather than only averages.

8. Set and communicate an SLE

Choose a relevant historical population and percentile. State item type, clock, confidence and exclusions. Review it when workflow or demand changes.

9. Improve experimentally

Change one policy, capacity allocation, hand-off or WIP limit with a prediction and guardrails. Observe end-to-end outcome, quality and flow before standardising.

10. Review the system

Periodically review demand, capacity, blocked reasons, classes of service, customer outcomes and policy fit. Escalate structural constraints rather than normalising heroic work.

AI automation lens

AI can classify items under approved rules, flag ageing or policy breaches, summarise blocked reasons, forecast probabilistic flow ranges and suggest questions for review.

It must not:

• silently reorder work or create an expedite class;
• promise a deterministic delivery date from a probabilistic distribution;
• optimise throughput by lowering quality or excluding difficult work;
• infer individual performance from card counts;
• expose sensitive card content;
• change WIP limits, completion definitions or customer commitments without authority.

Human service owners govern priority, policy, exceptions, risk and the definition of acceptable value.

Visual model

Text alternative: eligible options are pulled into capacity-limited Ready, Doing and Review states, then completed. Blocked and ageing signals prompt action, while flow measures inform policy experiments.

Interactive example

Scenario

An AI-content review team has 31 items in “In progress,” three reviewers and a daily stream of urgent labels. Work waits an average of nine days, but active review takes under two hours. Rejected items re-enter without their previous evidence.

Your move

Define a better workflow, one WIP limit, an expedite policy and two flow signals.

Worked answer

Use Options → Ready → Evidence check → Editorial review → Owner approval → Done, with a linked Rework state that preserves the rejection reason and evidence. Start with a WIP limit of six across the two review states—an initial hypothesis based on three reviewers and coordination cost. Only the duty editor can expedite a time-critical legal or public correction, one at a time, with the displaced item recorded.

Track work item age against an SLE and blocked time by reason; also monitor first-pass acceptance so throughput cannot improve by pushing defects forward. When the limit is reached, reviewers swarm to finish or unblock rather than pull more content.

Facilitation notes

• Use the work language people actually use, then make ambiguities explicit.
• Count waiting as part of flow even when nobody is actively working.
• Make policies readable from the board or one linked page.
• Ask why an item is ageing, not who is slow.
• Preserve history when work returns for correction.
• Review percentile distributions and outcomes, not only averages and velocity.

Expected output

• a bounded service and work-item definition;
• an explicit visual workflow with pull policies;
• WIP limits and governed exception rules;
• flow measures and an evidence-based SLE;
• blocked and ageing-item management;
• improvement cadence, experiments and owners.

Common mistakes

1. Board equals Kanban. Visualisation without flow policies changes little.
2. Unlimited urgent work. Expedites become a hidden second workflow.
3. Average as promise. Cycle time is a distribution; SLE is probabilistic.
4. Start-date ambiguity. Measures are incomparable when commitment points drift.
5. Local utilisation. Keeping everyone busy can increase end-to-end delay.
6. People metrics. Card counts encourage gaming and harm collaboration.

Quality checklist

• Service, customer, item and start/finish points are explicit.
• Actual states include waiting, review and rework.
• Entry, exit, pull, block and exception policies are visible.
• WIP limits have a rationale and override governance.
• Flow measures use stable clocks and populations.
• SLE states percentile, item type, time unit and evidence window.
• Quality and customer outcome guard throughput.
• Reviews change system policy rather than rank individuals.

Template

Use the structured Kanban workspace to define the system and record flow-review experiments.

Knowledge check

Question: A team exceeds its WIP limit every week because executives label new requests urgent. What is the best Kanban response?

A. Raise the limit automatically.
B. Define narrow expedite criteria, authority and capacity effect, then review the demand and policy evidence.
C. Hide urgent cards.
D. Stop measuring WIP.

Answer: B. An exception needs governance and a visible trade-off; repeated override is evidence that the system policy or demand model needs review.

Related tools

• Lean Management provides the wider value, waste and learning system.
• Value Stream Mapping diagnoses end-to-end flow and waiting at a defined point in time.
• Theory of Constraints focuses system improvement on the current limiting constraint.
• Critical Path Method schedules a one-off dependency network.
• PDCA/PDSA Cycle structures policy experiments.

References

1. Kanban Guides. The Kanban Guide, version 2025.5, May 2025. Official guide (opens in a new tab). Accessed 7 September 2026. The guide is licensed CC BY-SA 4.0; this Methodfield article uses original wording and provides attribution.
2. Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. Historical production-system context; knowledge-work adaptations require local validation.
3. Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010. Practitioner source for evolutionary knowledge-work application.

Method profile

• Primary output: governed pull system with explicit workflow and flow evidence.
• Decision level: recurring team or service operation.
• Evidence strength: medium to high after stable data definitions and sufficient history.
• Review trigger: demand, capacity, workflow, policy, distribution or customer-outcome change.