Kanban
Kanban is a method for managing work as continuous flow. Rather than planning work in fixed iterations, a team defines its workflow, makes it visible, limits how much work is in progress at once, and actively manages items so they finish quickly and predictably. It originated in Toyota's production system, was adapted to knowledge work by David J. Anderson and others in the 2000s, and is now widely used by software teams, especially those handling unpredictable demand — platform, operations, support, and many product teams.
Kanban's core insight is that starting less work finishes work sooner. A board with forty cards "in progress" shows lots of activity but little completion; items wait in queues, context switching grows, and nobody can say when anything will be done. Limiting work in progress, watching how long items have been in flight, and using flow data to forecast turns a busy board into a predictable delivery system.
TL;DR
- Define the workflow: what a work item is, where work starts and finishes, and the states in between.
- Visualize work on a board and make policies explicit — what each state means and when items may move.
- Limit WIP per state or for the whole system, and pull new work only when capacity frees up.
- Track the four flow measures: WIP, throughput, work item age, and cycle time.
- Set a service level expectation ("85% of items finish within 8 days") and act on items that age beyond it.
- Use classes of service for different urgency, and cadences for replenishment, delivery, and review.
Quick Example
Board policies a team agrees on and keeps next to the board:
Spotting aging work before it misses the service level expectation:
Core Concepts
Defining the Workflow
A Kanban system starts with a definition of workflow: what counts as a work item, the points where work is considered started and finished, the states items move through, how WIP is controlled, the explicit policies, and the service level expectation. Making these explicit is what lets a team discuss and improve how work flows, instead of arguing about individual tickets.
Visualization and Explicit Policies
The board shows every item and its state, including queues (waiting for review, waiting to deploy) that are invisible in many processes. Policies written on or near the board — entry criteria, WIP limits, how blocked items are handled, how urgent work enters — turn implicit habits into agreements the team can change deliberately.
Limiting Work in Progress
WIP limits per column, per person, or for the whole system make teams finish before starting. When a column is full, people help move existing items forward — reviewing, testing, unblocking — instead of starting new ones. Limits that are never reached are too high; limits that block constantly reveal a bottleneck to address.
Little's Law explains why it works: average cycle time equals average WIP divided by average throughput. For a stable system, halving WIP roughly halves the time each item takes.
Flow Measures
Cycle time scatterplots and cumulative flow diagrams show trends, outliers, and bottlenecks. Forecast with percentiles and Monte Carlo simulation on historical throughput ("85% chance of finishing these 20 items by 12 December") instead of estimating every item.
Service Level Expectations and Classes of Service
A service level expectation (SLE) states how long items typically take, with a confidence level, based on history. It sets expectations for stakeholders and tells the team when an item needs attention. Classes of service handle different urgency:
Cadences
Kanban decouples planning from delivery. Common cadences include replenishment (choosing what enters Ready, with stakeholders), delivery planning, flow reviews (looking at metrics and aging items), and retrospectives. Many teams also deploy continuously, so delivery is not tied to any meeting. See DORA Metrics.
Best Practices
Make Items Small and Similar in Size
Splitting large items makes flow smoother and forecasts more reliable.
Manage Aging Work Daily
In daily stand-ups, walk the board from right to left and focus on the oldest items first.
Reserve Capacity for Unplanned and Improvement Work
Allocate WIP or a class of service to support, incidents, and technical debt so they do not silently crowd out everything else.
Change Policies Deliberately
Treat WIP limits and policies as experiments; adjust them based on flow data and review the result.
Common Mistakes
A Board Without Limits
Measuring Only Throughput
Expedite as the Default
FAQ
What is Kanban in software development?
A method for managing work as continuous flow by visualizing the workflow, limiting work in progress, making policies explicit, and improving based on flow measures such as cycle time and throughput.
What are WIP limits?
Caps on how many items can be in a given state or in the whole system at once. They make teams finish work before starting new work, shortening cycle time.
What is the difference between cycle time and lead time?
Cycle time usually measures from when work starts to when it finishes; lead time often measures from when a request is made. Teams should define both explicitly for their workflow.
What is a service level expectation?
A forecast of how long a work item should take from start to finish, with a confidence level — for example, 85% of items within 8 days — based on historical cycle times.
Can Kanban and Scrum be used together?
Yes. Many Scrum teams add Kanban practices such as WIP limits, explicit policies, and flow metrics inside their Sprints. See Scrum vs Kanban.
Related Topics
- Agile Software Development — Values, principles, and frameworks
- Scrum vs Kanban — Choosing between iterations and flow
- Scrum — The iteration-based framework
- DORA Metrics — Delivery performance measures
- Team Topologies — Platform and enabling teams that often use Kanban
- Product Prioritization — Deciding what enters Ready
- Delivery Planning and Forecasting — Forecasting from throughput with Monte Carlo