Flow Metrics, Kanban vs. Scrum & Continuous Improvement

Cycle Time vs. Lead Time

Cycle time: from when active work STARTS to completion. Lead time: from when an item is first REQUESTED (even sitting in the backlog) to completion — always ≥ cycle time. A long lead time with short cycle time points to a queuing/prioritization problem; a long cycle time points to the actual work itself being slow.

Spotting Bottlenecks

A column where cards visibly pile up, or where WIP limits are frequently exceeded/adjusted, signals a bottleneck. A cumulative flow diagram shows this over time as stacked bands — a widening band for one stage means work is accumulating there faster than it moves forward.

Kanban vs. Scrum: Fit the Work Pattern

Scrum: fixed-length sprints, commit to a batch upfront — suits plannable, predictable feature work. Kanban: continuous flow, pull as capacity allows — suits unpredictable, interrupt-driven work (support, ops). Scrumban blends both: Scrum's structured ceremonies with Kanban's flow-based board instead of strict sprint commitment.

Continuous, Data-Driven Improvement

Kanban treats the workflow itself as never permanently fixed — regularly reviewing cycle time, lead time, and cumulative flow data to adjust WIP limits or reorganize stages based on real evidence, the same continuous-improvement ethos as Agile retrospectives.

Board Without Discipline

Using a board with To Do/In Progress/Done columns but never actually enforcing WIP limits or reviewing flow data captures Kanban's surface visual format while missing the behavioral discipline that produces its actual benefits — the same "cargo cult" pitfall discussed for superficial Scrum ceremony adoption.