When work piles up half-done, the usual response is to push harder: start more, so more gets finished. It does the opposite. Each extra item in progress makes everything else wait longer. Pull systems and work-in-progress (WIP) limits fix that by starting work only when there's room to finish it.
Where it comes from
Kanban (Japanese for "signboard") came from Toyota, where a card signaled that the next process had used parts and needed more. The Lean Enterprise Institute describes it as a pull system: the downstream step takes what it needs, and upstream makes only that. Software and office teams adopted kanban boards with WIP limits on each column.
The math behind it is Little's Law: in a stable process, average time in the system = average items in progress ÷ items finished per period. Halve the work in progress at the same finishing rate and the wait halves. See capacity and bottlenecks.
How a bot helps
A bot can build the board from the work records: every item, which column it's in, and how long it's been there. It counts each column against its limit and flags breaches and the oldest items. It can compute lead time and throughput weekly, so the effect of a limit shows in numbers.
It shouldn't set the limits itself. Start with today's count per column, lower it a little, and let the people doing the work adjust it.
On the bots' own work
A bot team pushes work easily: every bot can start a task at once. Without a limit, an analyst queue fills with half-done tickets. A WIP limit per bot, and a rule that blocked items get looked at before new ones start, keeps the queue moving.
When to use it
When lead times are long, half-done work piles up, or everything is "in progress". Light to set up; medium to tune.
Where bots differ
Bots don't get tired, so it's tempting to think limits don't apply. They do. The limit is on what people can review and approve, and that's usually the bottleneck.
Sources: Lean Enterprise Institute: kanban; Little (1961), A proof for the queuing formula L = λW.
Back to Engineering tools for bots.
Short outline
Kanban and WIP limits: short outline
What it's for
Kanban lets each step pull work only when it has room, and work-in-progress limits cap how much is started but not finished, which shortens lead time. Blocked items are cleared before new work starts.
Columns
| Column | What goes in it |
|---|---|
| Stage | One column on the board: a stage of the work, in order |
| Definition of done | What must be true to move an item out of this stage |
| WIP limit | The most items allowed in this stage |
| Current count | Items in the stage now |
| Oldest item | The item that has waited longest, and how long |
| Blocked | Items that can't move, each with what they wait on |
| Lead time | Average start-to-finish time, by week |
| Throughput | Items finished per week |
Steps, each with its "done when"
- Map the columns from the real work. Done when each column is a stage the work actually passes through, with a definition of done.
- Count what is in each column now. Done when every open item is placed in one column, and the oldest is noted.
- Set the first limits. Done when each column has a WIP limit at or a little below today's count, agreed by the people doing the work.
- Add the pull and blocker rules. Done when the rule says work starts only when a column is under its limit, and blocked items are reviewed before new work starts.
- Measure and adjust. Done when lead time and throughput are recorded weekly, and limit changes are logged with their reason.
Common mistakes
- Limits set so high they never bind.
- Starting new work to keep busy while items are blocked.
- A board that describes the org chart instead of the work.
- Forgetting that a person's review is a column, and usually the bottleneck.