kanban

Kanban is a workflow management method that visualizes a team’s work as cards on a board and limits how many items can be in progress at once, so each new task is pulled forward only when capacity frees up. The name is the Japanese word for signboard, and the method grew out of the just-in-time production system Toyota developed in the 1950s, which David J. Anderson adapted for software and other knowledge work in the mid-2000s.

A kanban board makes the state of every task visible at a glance, and the number beside each column caps how much work is allowed to sit there:

Backlog    To Do (3)   In Progress (2)   Review (2)   Done
-------    ---------   ---------------   ----------   ----
RP-115     RP-108      RP-104            RP-101       RP-097
RP-116     RP-109      RP-103                         RP-098

How It Shows Up in Practice

A Python developer usually meets kanban as the board their team runs the day on, in tools such as Jira, Trello, or GitHub Projects. Each card is one work item, often a user story or a bug, and it moves left to right across columns that mirror the team’s real workflow rather than a fixed set of stages.

Two rules give the board its teeth. The first is the work-in-progress limit, also called the WIP limit, the small number written at the top of a column that caps how many cards may sit in it. The second is pull: a developer takes the next card only when finishing one of their own frees a slot, which is why kanban teams repeat the phrase stop starting, start finishing.

A column that is full blocks anyone from pushing more work into it, so a bottleneck becomes visible instead of hidden, which the board makes plain at a glance:

Because the board never empties and resets, teams judge their health by flow metrics instead of a per-iteration score. Cycle time measures how long a card takes from the moment work starts to the moment it ships, lead time measures the wait from first request to delivery, and throughput counts how many cards finish per week. Watching those numbers is what turns the board from a status display into a tool for spotting where work piles up.

Kanban vs. Scrum

Both Kanban and Scrum are ways to run agile work, and teams routinely mix the two up. Scrum slices time into fixed sprints, commits to a batch of work for each one, and clears the board when the sprint ends. Kanban keeps a single continuous flow with no required sprints, no prescribed roles, and a board that carries on.

The practical tell is what happens when priorities shift. A Scrum team usually waits for the next sprint boundary to change course, while a kanban team reorders the cards waiting in its backlog and lets the WIP limits pace the rest. Many teams blend the two into a hybrid often called Scrumban. To see how the time-boxed side sizes its upcoming work, read story points.