What Is a Kanban Board?
A Kanban board is a visual tool that represents work items as cards, organized into columns that reflect stages of a workflow, typically at minimum To Do, In Progress, and Done. Team members move cards across columns as work progresses, which makes the current state of all work visible to everyone at once. Kanban originated in Toyota's manufacturing system and was later adapted for knowledge work and software teams, where tools like Trello, Jira, and Asana implement it digitally.
A Kanban board is a visual work management tool that shows tasks as cards moving through columns like To Do, In Progress, and Done, making bottlenecks and workload visible at a glance.
Kanban’s core idea sounds almost too simple to matter: make all the work visible on a board, and limit how much is in progress at once. In practice, this single constraint changes how teams behave more than most process frameworks that are far more elaborate on paper.
Where Kanban came from
Kanban originated at Toyota in the 1940s as part of its manufacturing system, where physical cards signaled when a workstation needed more parts, preventing overproduction and keeping inventory lean. The concept was adapted for software and knowledge work in the late 2000s, most notably popularized by David J. Anderson, and now shows up as a board view in essentially every project management tool.
The three core practices
Visualize the workflow: every piece of work becomes a card, and every stage of your process becomes a column, so the full state of ongoing work is visible in one glance rather than scattered across emails and status meetings. Limit work in progress: each column, or the board as a whole, gets a cap on how many cards can be active at once, which forces the team to finish work before starting more. Manage flow: the team regularly reviews how smoothly cards move across the board, identifying where cards pile up or sit stuck, since that pile-up is the clearest signal of a bottleneck.
Why WIP limits are the part people skip
Most teams that adopt a board format still skip the WIP limit, and that is usually where the benefit is lost. Without a limit, it is easy to start five things at once because it feels productive, while nothing actually finishes and gets delivered. A WIP limit forces a harder but more honest question whenever someone wants to start new work: what existing item will get blocked or delayed as a result. That friction is intentional; it is what exposes bottlenecks instead of hiding them under a long list of half-finished tasks.
Kanban versus Scrum in practice
Kanban suits work that arrives unpredictably and continuously, support tickets, maintenance requests, ad hoc client work, where committing to a fixed two-week sprint plan does not match reality. Scrum suits work that can be planned in discrete, deliverable chunks, like a defined set of product features for a release. Many teams end up using a hybrid, running Kanban day-to-day while still reviewing progress on a regular cadence borrowed from Scrum.
Getting started
A team new to Kanban does not need software on day one. A whiteboard with three columns and sticky notes for cards is enough to test whether visualizing work changes how the team prioritizes. Once that habit sticks, moving to a digital tool like Trello, Jira, or Asana adds automation, notifications, and historical metrics like average cycle time, without changing the underlying method.
Our tip: Start with a strict WIP limit even if it feels artificially tight, for example limiting ‘In Progress’ to one card per person. Teams almost always resist this at first and then discover within a week or two how much faster work actually finishes when they are not juggling five half-done tasks at once.
Frequently asked questions
What is the difference between Kanban and Scrum?
Scrum organizes work into fixed-length sprints, usually one to four weeks, with a defined set of work committed to at the start of each sprint and a review at the end. Kanban has no sprints or fixed commitments; work flows continuously, and new items can be added or reprioritized at any time as long as work-in-progress limits are respected. Kanban is generally a better fit for teams with unpredictable, ongoing work like support or maintenance, while Scrum suits teams delivering discrete, plannable chunks of work.
What are work-in-progress (WIP) limits and why do they matter?
A WIP limit caps how many cards can sit in a given column at once, for example allowing no more than three cards in the 'In Progress' column at a time. The purpose is to prevent a team from starting many tasks simultaneously without finishing any of them, which slows down actual delivery even though it feels productive. When a column hits its limit, the team must finish or unblock existing work before starting anything new, which surfaces bottlenecks quickly instead of hiding them behind a long list of half-done tasks.
Do I need software to use Kanban, or can it work on a physical board?
Kanban started as a physical system, literally cards and a board on a factory wall, and a whiteboard with sticky notes works perfectly well for a small, co-located team. Digital tools like Trello, Jira, Asana, or Azure DevOps Boards become worthwhile once a team is distributed across locations, needs automated notifications, or wants to track historical metrics like cycle time. The underlying principle, visualizing flow and limiting work in progress, is identical either way.
How many columns should a Kanban board have?
There is no fixed number; it should reflect your actual workflow. A simple setup uses three columns: To Do, In Progress, Done. More detailed workflows might add columns like 'In Review' or 'Blocked' to reflect real stages the work passes through. The guiding principle is to model your actual process, not to copy a template, and to avoid adding so many columns that the board becomes harder to read at a glance than the workflow it represents.