TechLead
Lesson 6 of 30
5 min read
Project Management

Kanban Method

Learn the Kanban method from its Toyota origins to modern software development, including WIP limits, flow metrics, and when to choose Kanban over Scrum

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. 1. Visualize the Workflow: Make all work visible on a board so everyone can see the status of every item.
  2. 2. Limit Work in Progress (WIP): Set explicit limits on how many items can be in each column/state at any time.
  3. 3. Manage Flow: Monitor and optimize the smooth movement of work through the system.
  4. 4. Make Policies Explicit: Document and display the rules for how work moves through the board.
  5. 5. Implement Feedback Loops: Regular cadences (standups, reviews, retrospectives) to inspect and adapt.
  6. 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 TimeTime from request to deliveryDelivery date - request dateCustomer perspective: how long do they wait?
Cycle TimeTime from work started to deliveryDelivery date - start dateTeam perspective: how long does work take?
ThroughputNumber of items completed per time periodItems done / time periodTeam capacity and predictability
WIPItems currently in progressCount of active itemsLittle'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
CadenceFixed sprints (1-4 weeks)Continuous flow
RolesPO, SM, Dev Team (required)No prescribed roles
PlanningSprint Planning every sprintOn-demand replenishment
ChangeNo changes during sprintChanges can happen anytime
MetricsVelocity, burndownCycle time, throughput, lead time
BoardReset each sprintPersistent, always evolving
EstimationStory points requiredOptional (size-based is common)
Best ForProduct development teamsSupport, 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

Continue Learning