Origins of Kanban
Kanban (meaning "visual signal" or "card" in Japanese) originated in Toyota's manufacturing system in the late 1940s. Taiichi Ohno developed it as a scheduling system for just-in-time (JIT) manufacturing, where production signals flow upstream to indicate when new parts are needed.
In 2007, David J. Anderson adapted Kanban for knowledge work and software development. Unlike Scrum, Kanban does not prescribe specific roles, ceremonies, or time-boxed iterations. Instead, it focuses on visualizing work, limiting work in progress, and optimizing flow.
The Six Kanban Practices
- 1. Visualize the Workflow: Make all work visible on a board so everyone can see the status of every item.
- 2. Limit Work in Progress (WIP): Set explicit limits on how many items can be in each column/state at any time.
- 3. Manage Flow: Monitor and optimize the smooth movement of work through the system.
- 4. Make Policies Explicit: Document and display the rules for how work moves through the board.
- 5. Implement Feedback Loops: Regular cadences (standups, reviews, retrospectives) to inspect and adapt.
- 6. Improve Collaboratively, Evolve Experimentally: Use scientific method to make incremental changes.
WIP Limits: The Heart of Kanban
WIP limits are the single most important Kanban practice. Without them, a Kanban board is just a task board. WIP limits force the team to finish work before starting new work, which reduces context switching, exposes bottlenecks, and improves flow.
Setting WIP Limits
- Rule of Thumb: Start with WIP limit = number of team members in that stage, then reduce over time
- Too High: No benefit — work piles up, context switching remains high
- Too Low: Team members are idle waiting for WIP slots — indicates bottleneck elsewhere
- Goal: Find the sweet spot where flow is smooth and bottlenecks are visible
Flow Metrics
| Metric | Definition | Formula | Why It Matters |
|---|---|---|---|
| Lead Time | Time from request to delivery | Delivery date - request date | Customer perspective: how long do they wait? |
| Cycle Time | Time from work started to delivery | Delivery date - start date | Team perspective: how long does work take? |
| Throughput | Number of items completed per time period | Items done / time period | Team capacity and predictability |
| WIP | Items currently in progress | Count of active items | Little's Law: Lead Time = WIP / Throughput |
Kanban Board Data Model
// Kanban Board Data Model
interface KanbanBoard {
id: string;
name: string;
columns: KanbanColumn[];
policies: BoardPolicy[];
metrics: FlowMetrics;
}
interface KanbanColumn {
id: string;
name: string;
wipLimit: number;
currentWIP: number;
items: KanbanItem[];
subColumns?: { name: string; items: KanbanItem[] }[]; // e.g., "Doing" | "Done"
}
interface KanbanItem {
id: string;
title: string;
type: 'feature' | 'bug' | 'improvement' | 'urgent';
priority: 'expedite' | 'high' | 'medium' | 'low';
assignee: string | null;
createdDate: Date;
startedDate: Date | null;
completedDate: Date | null;
blockedSince: Date | null;
tags: string[];
size: 'S' | 'M' | 'L' | 'XL';
}
interface BoardPolicy {
column: string;
rules: string[];
}
interface FlowMetrics {
averageLeadTime: number; // days
averageCycleTime: number; // days
throughput: number; // items per week
wipAge: { itemId: string; age: number }[]; // how long items have been in WIP
}
// Example Kanban board for a dev team
const devBoard: KanbanBoard = {
id: 'board-1',
name: 'Platform Team',
columns: [
{
id: 'col-1',
name: 'Backlog',
wipLimit: 20,
currentWIP: 15,
items: [],
},
{
id: 'col-2',
name: 'Ready',
wipLimit: 5,
currentWIP: 3,
items: [],
},
{
id: 'col-3',
name: 'In Development',
wipLimit: 4,
currentWIP: 4,
items: [],
subColumns: [
{ name: 'Coding', items: [] },
{ name: 'Code Review', items: [] }
]
},
{
id: 'col-4',
name: 'Testing',
wipLimit: 3,
currentWIP: 2,
items: [],
},
{
id: 'col-5',
name: 'Done',
wipLimit: Infinity,
currentWIP: 42,
items: [],
}
],
policies: [
{
column: 'Ready',
rules: [
'Item has clear acceptance criteria',
'Dependencies are resolved',
'Item is estimated (S/M/L/XL)'
]
},
{
column: 'In Development',
rules: [
'Developer has pulled the item (not assigned)',
'Branch created from main',
'Move to Code Review when PR is opened'
]
},
{
column: 'Testing',
rules: [
'All automated tests pass',
'Manual testing for UI changes',
'Move to Done when QA approves'
]
}
],
metrics: {
averageLeadTime: 8.5,
averageCycleTime: 4.2,
throughput: 12,
wipAge: []
}
};
// Calculate flow efficiency
function calculateFlowEfficiency(
activeTime: number,
totalLeadTime: number
): number {
// Flow efficiency = active time / total lead time
// Typical teams: 15-40%, World class: 40%+
return (activeTime / totalLeadTime) * 100;
}
// Little's Law calculator
function predictLeadTime(wip: number, throughput: number): number {
// Lead Time = WIP / Throughput
return wip / throughput;
}
Kanban vs. Scrum Comparison
| Aspect | Scrum | Kanban |
|---|---|---|
| Cadence | Fixed sprints (1-4 weeks) | Continuous flow |
| Roles | PO, SM, Dev Team (required) | No prescribed roles |
| Planning | Sprint Planning every sprint | On-demand replenishment |
| Change | No changes during sprint | Changes can happen anytime |
| Metrics | Velocity, burndown | Cycle time, throughput, lead time |
| Board | Reset each sprint | Persistent, always evolving |
| Estimation | Story points required | Optional (size-based is common) |
| Best For | Product development teams | Support, ops, maintenance, flow-based work |
When to Choose Kanban
- Support/Operations Teams: Work arrives unpredictably and cannot wait for sprint boundaries
- Continuous Delivery: Team deploys multiple times per day
- Maintenance Work: Bug fixes and small enhancements with varying priority
- Transitioning to Agile: Kanban is less disruptive to adopt — start where you are
- Mixed Work Types: Team handles a mix of features, bugs, and operational work