Visualizing work and limiting in-progress
Kanban organizes work into visible states: typically backlog (not started), doing (in progress), review (waiting for feedback), and done (shipped). Each column on the board is a queue. Work flows left to right. The key innovation is the WIP limit (work in progress): the maximum number of items allowed in each column at the same time. A team might limit 'doing' to 8 items and 'review' to 5.
WIP limits prevent context-switching chaos and create pull-driven work. Without limits, engineers take new tasks whenever they finish one, and backlogs pile up without flowing through review or blocked on dependencies. With limits, when 'doing' is full, no one takes new work until someone moves an item to review, which creates a gentle pressure to complete and ship.
Flow metrics and continuous improvement
Kanban teams track three metrics: throughput (items shipped per week), cycle time (how long an item spends on the board), and flow efficiency (percentage of cycle time spent actually working vs waiting). A healthy team has stable throughput week to week, cycle time below 10 days, and flow efficiency above 60 percent. When any metric degrades, it signals a bottleneck: either WIP limits are too tight, or work is getting blocked.
The discipline of Kanban is that you manage to the metrics, not to the team. If cycle time is growing, you do not tell the team to work faster; you investigate why items are waiting longer. Is review taking too long? Are dependencies blocking work? Are WIP limits too aggressive? Kanban creates the instrumentation to diagnose problems, not just symptoms.