Kanban is a way of managing work by putting every task on a board where everyone can see it, then limiting how many tasks are in progress at once. The board takes minutes to set up. The limit is what makes it more than a to-do list.
What a Kanban board shows
A Kanban board is split into columns, and each column is a state that work can be in. The simplest board has three:
- To Do: work that has been asked for but not started.
- Doing: work someone is actively on.
- Done: work that is finished.
Each task becomes a card: one card for a dark mode toggle, one for a login bug, one for the checkout page. A card holds a short title and, in most tools, a description, an owner and a few labels. Its position on the board says what state it is in, so the board answers three questions at a glance: what is waiting, what is in progress, and what is finished.
That visibility is the first benefit. When tasks live in people's heads, in chat threads and in scattered notes, nobody can see the whole picture, including the person doing the work. Put them on one board and problems show up on their own: a column that keeps growing, a card that has not moved for a week, three people all working on 'urgent' things at the same time.
The word comes from Japanese, where kanban means a signboard or visual card. Toyota used physical cards on its factory floor to signal when more parts were needed, and software teams later borrowed the idea for knowledge work.
How work moves across the board
A card moves from left to right as its state changes. When someone starts a task, its card moves from To Do into Doing. When they finish it, the card moves into Done.
In Kanban, people pull work: when you have room, you take the next card from To Do. Work is not pushed onto you the moment it arrives. To make pulling work well, keep the To Do column in priority order, with the most important card at the top, so the next card anyone pulls is the right one.
Columns that match your process
To Do, Doing and Done is a starting point, not a rule. Most teams split Doing into the real steps their work goes through. A typical software team's board might read:
- Backlog
- Ready
- Building
- In review
- Testing
- Done
A column should exist only if work waits or changes hands there. A 'Review' column is useful because a card can sit there for a day waiting for a reviewer, and the board should show that. A column for every small action makes the board harder to read without telling anyone anything new.
Limiting work in progress
Kanban's central rule is to avoid doing too many things at once. Teams put this into practice with a work-in-progress (WIP) limit: a maximum number of cards allowed in a column. A team of three might set Doing to a limit of three.
When a column is full, nobody pulls a new card into it. Instead, the person who would have started something new helps finish what is already there: they review a pull request, pair on a stubborn bug or chase the answer that is blocking a card.
Why fewer tasks finish sooner
Starting more work at once feels productive, but it slows each piece down.
- Switching costs time. Every time you jump between tasks you have to reload the context of the one you return to: where you were and what you had already tried.
- Half-done work delivers nothing. Ten features at 80% give users nothing. Two features at 100% can ship today.
- Waiting hides in a crowded column. With fifteen cards in Doing, a card stuck waiting for a reviewer is easy to miss. With three, it stands out.
There is a simple relationship behind this, known as Little's Law: at a steady rate of finishing work, the more items you have in progress, the longer each one takes on average. Cutting what is in progress is the most direct way to get each piece of work finished sooner.
Measuring the flow
Once a board has been in use for a few weeks, it can tell a team how well work flows. Two common measures are cycle time, how long a card takes from starting to finishing, and throughput, how many cards are finished in a week. If cycle time keeps rising, look for where cards wait longest. That column is the bottleneck, and the place to improve first.
A worked example
A two-person team is building a small online shop. Their board has four columns: To Do, Doing (limit 2), Review (limit 2) and Done. On Monday morning it looks like this:
- To Do: checkout page, dark mode toggle, product search
- Doing: login bug (Sam), order emails (Priya)
- Review: empty
Sam fixes the login bug and moves the card to Review. Doing now has a free slot, so Sam pulls the next card from the top of To Do, the checkout page.
On Tuesday Priya finishes the order emails and moves them to Review. Doing has room again, so she could pull the dark mode toggle. But Review is now full: both cards there are waiting for a reviewer, and anything new she finished would have nowhere to go. So instead of starting something, Priya reviews Sam's login fix, which moves to Done. That frees a slot in Review, and Sam reviews the order emails that afternoon.
Without the limits, both of them would have kept starting new cards, and by Friday the board could show six things in progress and nothing in Done. With the limits, two pieces of work were finished and shipped by Tuesday evening, while Doing holds only the checkout page.
Not just for software
Nothing about a Kanban board is specific to code. Anything made of separate tasks can go on one:
- planning a team's project or a product launch;
- running a support queue, where tickets arrive at unpredictable times;
- a hiring pipeline, with columns for applied, interviewing and offered;
- household chores, or anything else you keep forgetting to finish.
A personal board with a limit of two or three in Doing is a good way to try Kanban before suggesting it to a team.
Kanban compared with Scrum
Kanban is widely used by Agile teams, and it is often compared with Scrum. The boards can look alike, but the two work differently:
- Scrum plans work in fixed sprints, often two weeks long, with set roles and a set of meetings. The team commits to a batch of work at the start of each sprint.
- Kanban has no sprints and requires no roles. Work flows continuously, and a new card can be pulled the moment there is room for it.
That makes Kanban a good fit for work that arrives unpredictably, such as support or operations, and for small teams that find Scrum's structure heavy. Scrum suits a team building a product feature by feature towards a regular review. Many teams mix the two, for example running sprints but with WIP limits on the board. For a wider comparison, including Waterfall and Agile, see Development Methodologies.
Common mistakes
- No WIP limits: a board without limits is a to-do list with columns. The limit is what changes how people work.
- Cards that are too big: 'Build the shop' sits in Doing for a month and tells nobody anything. Split work into cards that finish in a day or two.
- Too many columns: each extra column is another place for work to wait. Start simple and add a column only when the work pauses there.
- Stale cards: a board that nobody updates is worse than no board, because it gives a false picture. Move cards as the work changes, not at the end of the week.
- Blocked work left in Doing: a card waiting on someone else still uses up a slot. Mark it as blocked and make clearing the blocker a priority, rather than quietly starting something else.
Key takeaways
- Kanban makes work visible: every task is a card, and each column shows a state such as To Do, Doing or Done.
- People pull the next card when they have room, rather than having work pushed onto them.
- Work-in-progress limits are the core rule: finish what is in progress before starting something new.
- Fewer tasks in progress means each one finishes sooner, with less context switching and fewer hidden delays.
- Kanban suits any work made of separate tasks, software or otherwise.
