Skip to content

Kanban

Kanban is a method for managing work as a continuous flow rather than in timeboxes. It came from Toyota's production system, where a kanban was a physical card authorizing the next piece of work. Software Kanban keeps the core idea: work is pulled, never pushed.

Kanban is not a development process. It defines no roles, no ceremonies and no iterations. It is a set of practices layered on top of whatever a team already does, which is why adopting it is non-disruptive.

The core practices

  1. Visualize the workflow. Every step from request to release becomes a column, and every item becomes a card. You cannot improve a process you cannot see.
  2. Limit work in progress. Each column gets an explicit WIP limit. See WIP Limits and Flow Metrics.
  3. Manage flow. Watch how work moves, hunt for where it waits, and reduce that.
  4. Make process policies explicit. Write down what "ready for review" means, so the rules stop being folklore.
  5. Implement feedback loops. Standups, replenishment and delivery reviews, on whatever cadence fits.
  6. Improve collaboratively, evolve experimentally. Change the system in small measured steps, not in a reorganization.

A board

flowchart LR
    subgraph BL[Backlog]
        b[...]
    end
    subgraph RD["Ready, limit 3"]
        A(A) ~~~ B(B) ~~~ C(C)
    end
    subgraph DV["Dev, limit 2"]
        D(D) ~~~ E(E)
    end
    subgraph RV["Review, limit 2"]
        F(F)
    end
    subgraph TS["Test, limit 2"]
        G(G) ~~~ H(H)
    end
    subgraph DN[Done]
        d[...]
    end
    BL --> RD --> DV --> RV --> TS --> DN

The numbers are WIP limits. When Dev is full, a developer finishing an item cannot start a new one. They go help move F out of Review instead. That is the mechanism: limits convert individual busyness into collective flow.

Push versus pull

graph TD
    subgraph Push[Push system, no limits]
        R1[Requests] --> D1[Dev] --> V1[Review] --> T1[Test] --> O1[Done]
        V1 -. queue grows .- Q1[(Waiting)]
    end
    subgraph Pull[Pull system, WIP limited]
        R2[Requests] --> D2["Dev (2)"] --> V2["Review (2)"] --> T2["Test (2)"] --> O2[Done]
        V2 -. full, so Dev cannot start more .- D2
    end

In the push system every station works flat out and the queues in front of the slow step grow. In the pull system a full downstream column stops the upstream one, so the bottleneck becomes visible on the first day instead of at the deadline.

Kanban compared to Scrum

Scrum Kanban
Cadence Fixed Sprints Continuous flow, optional cadences
Commitment Sprint Goal per Sprint No timebox commitment
Roles Three prescribed None prescribed
Change during work Sprint scope is protected Re-prioritize any time capacity frees up
Core metric Velocity Cycle time and throughput
Adoption Replaces the current process Starts from the current process
Best fit Product development with a shared goal Support, operations, and varied unplanned work

Neither is stricter about quality. Both depend on the team's engineering practices.

When Kanban fits better

  • Work arrives unpredictably and cannot wait for the next Sprint, as in support, operations or incident response.
  • Item sizes vary wildly, which makes Sprint commitments meaningless.
  • The team is a service to many requesters rather than one product.
  • A Scrum adoption would be too disruptive, and you want evolutionary change.

Scrumban

Scrum's cadence and roles with Kanban's WIP limits and flow metrics. A common landing spot for teams whose Sprint commitment keeps getting broken by urgent work, and who want the interruptions made visible rather than pretended away.

Check Your Understanding

#

What does a WIP limit actually change about how a team behaves?

#

A support team handles unpredictable incidents alongside planned work. Which fits better?

Assessment

Work through the Flow, Kanban and Lean assessment once you have read this section.