What Is Kanban? (And How Teams Use It Beyond Software)

Kanban is a visual workflow method that moves work across a board from to-do to done, with limits on how much can be in progress at once. It makes bottlenecks obvious and keeps work flowing.

The appeal of Kanban is that you can understand it in one glance. Cards are tasks. Columns are stages. A card moves left to right as the work progresses. Anyone walking past the board can see what is happening, what is stuck, and who is buried, without asking a single person for a status update. That visibility is the entire point.

Kanban started on a factory floor at Toyota, not in software, which is worth remembering given how often it gets boxed in as an engineering tool. As the Kanban Method is defined today, it is about flow, and flow matters to any team with work moving through stages, from marketing to operations to support. For where it sits among the other approaches, see our project management glossary.

What are the principles of Kanban?

Kanban runs on a few simple ideas that work together.

• Visualize the work. Put every task on a board so the whole flow is visible. You cannot manage what you cannot see.
• Limit work in progress. Cap how many tasks can sit in any stage at once. This is the rule that makes Kanban more than a to-do list.
• Manage flow. Watch where cards pile up. A column that keeps filling is a bottleneck asking for attention.
• Make the rules explicit. Everyone should know what “done” means for each column, so cards do not move on a hunch.

The discipline is in the work-in-progress limit. Without it, a board is just a prettier task list.

What is a Kanban board?

A Kanban board is the visual heart of the method. In its simplest form it has three columns: To Do, Doing, and Done. Tasks start as cards in the first column and move right as they progress.

In practice, boards get more specific. A content team might use Ideas, Drafting, In Review, Approved, and Published. A support team might use New, In Progress, Waiting on Customer, and Resolved. The columns map to the actual stages your work moves through, so the board mirrors how your team really operates.

The board can be a physical wall of sticky notes or a digital version. The format matters less than the habit of keeping every piece of work visible in one place.

What is the difference between Kanban and Scrum?

Both are agile, and people often weigh them against each other, so here is the clean distinction.

Scrum works in fixed sprints. You commit to a set batch of work for one to four weeks, then stop, review, and plan the next sprint. It has defined roles and a set rhythm.

Kanban has no sprints. Work flows continuously, pulled into progress as capacity opens up, with no fixed start and stop. It has no required roles.

So Scrum is a series of timed batches. Kanban is a steady stream. Scrum suits teams that benefit from a planning cadence and a hard reset every couple of weeks. Kanban suits teams with a continuous flow of incoming work, like support, operations, or a marketing team fielding requests all week. Many teams blend them, running a Scrum rhythm on a Kanban board.

What does a work-in-progress limit do?

A work-in-progress limit caps how many tasks are allowed in a stage at the same time. If the “Doing” column has a limit of three, nobody starts a fourth task until one of the three moves on.

It sounds restrictive, but it’s actually the feature that makes Kanban work. When everyone is allowed to start everything, you get a board full of half-finished tasks and nothing crossing the finish line. A work-in-progress limit forces the team to finish what is started before pulling in more. It turns “we are busy on twelve things” into “we are actually completing things.”

The limit also exposes bottlenecks instantly. When a column hits its cap and stays there, you can see exactly where work is jamming up and fix that stage of guessing. It is the same idea behind capacity planning: match the work in flight to what the team can actually handle.

Kanban for teams that do not write code

Most Kanban tools were built with software teams in mind, and it shows. The boards assume engineering stages, the integrations point at code repositories, and a marketing or operations team ends up bending a developer tool to fit work it was never designed for.

That is backwards for most of the teams that would benefit from a board. Workzone started as an agency more than two decades ago, so the board views were built for creative, marketing, and operations flow from the beginning, not adapted from an engineering tool. The columns map to how your team actually works, the cards carry the files and approvals the work needs, and nobody has to learn a system meant for developers. You get the visual flow of Kanban for the kind of work your team actually does.

See the board view in Workzone →

Frequently asked questions

What is Kanban in simple terms?
Kanban is a way of managing work by putting every task on a board as a card and moving it across columns from to-do to done. You limit how many tasks can be in progress at once, which keeps work flowing and makes it obvious where things are getting stuck.

Is Kanban agile?
Yes. Kanban is one of the main agile methods, alongside Scrum. It follows agile principles by keeping work visible, flexible, and continuously flowing, though unlike Scrum it does not use fixed sprints. Many agile teams use Kanban on its own or blend it with a Scrum cadence.

What teams use Kanban?
Kanban started in manufacturing and spread to software, but it works for any team with work moving through stages. Marketing, operations, support, agencies, and creative teams all use Kanban boards to track requests and keep work flowing. It is especially useful for teams fielding a continuous stream of incoming work rather than discrete projects, because the board absorbs new requests without forcing a full replan.

What is a work-in-progress (WIP) limit?
A work-in-progress limit is a cap on how many tasks are allowed in a single stage at the same time. It is the rule that makes Kanban work: rather than starting everything at once, the team finishes what is already in flight before pulling in more. WIP limits keep work moving and make a bottleneck obvious the moment a column fills up, which is what turns a board from a pretty to-do list into a working flow system.

Is Kanban better than Scrum?
Neither is better in the abstract; they suit different work. Scrum helps teams that benefit from a planning cadence and a fixed sprint, while Kanban helps teams with a steady, continuous flow of incoming requests. Many teams happily combine them, running a Scrum rhythm on a Kanban board, so the most useful question is not which is better but which matches how your work actually arrives.

---

Related reading: What Is a Gantt Chart?