What It Actually Means
That limit is not a detail. It is the entire mechanism, and it is the part people leave out when they say they are doing kanban.
Why The Limit Is The Point
Without it, a board is a to-do list on a wall.
The limit forces something uncomfortable and useful: when a column is full, you cannot start anything new. You have to finish or unblock something first. That converts the usual state of twelve things in progress and nothing finished into fewer things moving faster.
It also makes bottlenecks impossible to hide. If work keeps piling up before testing, the board shows it, in the same place, every day. Everyone can see where the constraint is instead of arguing about who is behind.
The instinct to start something else when blocked is exactly what the limit exists to prevent, which is why teams resist it and why it works.
Where It Beats Sprints
Scrum commits to a set of work for a fixed period. That is excellent for building something and poor for work that arrives without warning.
Support, maintenance and operations do not fit a two-week commitment. Tuesday’s urgent problem reorders everything, the sprint commitment is missed, and the process gets blamed for what is actually a mismatch between the method and the work.
Kanban handles that naturally. There is no commitment to break, priorities are reordered continuously, and urgent items go to the front. For a support arrangement it is usually the right shape.
It also suits small teams and single developers, where the ceremony of scrum costs a meaningful share of the available time.
What To Watch
No limits. The most common failure. A board with no work-in-progress limits gives you visibility and none of the benefit.
No dates, ever. Kanban has no sprint boundary, so it can drift into never committing to anything. Flow metrics answer this: how long items actually take from start to finish, measured rather than estimated. A team using kanban well can tell you that a typical item takes six days and ninety percent finish within twelve. That is a forecast, and it is a better one than most estimates.
Everything urgent. If every item enters at the front, there is no queue and no flow, only interruption.
A board nobody looks at. It has to reflect reality daily to be worth anything.
What To Ask
- What are the work-in-progress limits? If there are none, this is not kanban.
- How long does a typical item take, start to finish? A well-run board can answer with data.
- Where does work pile up? The team should know, because the board shows it.
- How do urgent items get in, and what gets displaced? There should be a rule rather than a habit.
Choosing Between Them
The question is not which is better, it is what the work looks like.
Predictable, planned, project-shaped work with a defined outcome suits sprints. Reactive, continuous, unpredictable work suits kanban. Plenty of arrangements sensibly run both: sprints for the build, kanban for support alongside it.
A supplier proposing sprints for maintenance, or continuous flow for a fixed-scope build with a deadline, has chosen the process before looking at the work.
More terms are in the glossary.
