Kanban: Boards, WIP Limits & Kanban vs Scrum [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on July 29, 2026
12 min read
Kanban is deceptively simple — a board, some columns, and cards you move from left to right. Almost everyone has seen one, and plenty of teams think a board full of sticky notes means they're "doing Kanban." But the board is just the visible surface; the real method is about limiting how much work is in progress and managing how smoothly it flows. This guide explains Kanban in full — what it is, where it came from, the board, WIP limits, its core practices, how it compares to Scrum, and how it appears on the PMP and CAPM exams.
What is Kanban?
Kanban is a visual method for managing work as it flows through a process, designed to deliver continuously without overloading the team. Work items are represented as cards on a board, moving through columns that represent the stages of the workflow, so that everyone can see at a glance what's being worked on, what's waiting, and what's done.
The name comes from Japanese, where kanban means "visual signal" or "card" — a nod to the method's roots in physical signaling systems. But Kanban is more than a board: at its heart it's a way of managing flow by making work visible, limiting how much is in progress at once, and continuously improving how work moves through the system. Unlike frameworks that reorganize a team into new roles and cycles, Kanban is evolutionary — you start with your existing process exactly as it is and improve it gradually. That gentle, overlay-on-what-you-already-do quality is a big part of why it's so widely adopted.
The origins of Kanban
Kanban began on the factory floor at Toyota in the 1940s and 1950s, as part of the Toyota Production System developed by Taiichi Ohno. There, kanban cards were physical signals used to trigger the replenishment of parts only when they were actually needed — a pull-based, just-in-time system that kept inventory low and production flowing smoothly. When a station needed more parts, a card signaled upstream to produce them; nothing was made "just in case."
Decades later, that same idea was adapted from manufacturing to knowledge work. Around 2007, David J. Anderson formalized the Kanban Method for software development and other knowledge-based teams, translating Toyota's physical signaling into a system of visual boards, work-in-progress limits, and flow management. The shared thread across both worlds is the same: pull work through the system based on real capacity, limit how much is in progress, and let that discipline smooth out the flow. Kanban's manufacturing heritage is also why it sits comfortably alongside lean project management, with which it shares deep roots.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
The Kanban board
The Kanban board is the method's signature tool — a visual representation of the workflow, divided into columns for each stage that work passes through, with each work item shown as a card that moves left to right as it progresses. At its simplest, a board has three columns: To Do, In Progress, and Done. Real boards often add stages like review or testing to mirror the team's actual process.
What turns a board from a simple task list into a Kanban system is what's attached to it: a work-in-progress limit on the columns (the "WIP 3" above), and the discipline of pulling work through it. A board alone just shows work; a Kanban board governs it. Because the Kanban board is such a rich topic in its own right — column design, swimlanes, card details, and policies — it deserves a deeper treatment than we can give it here, but the core idea is this: make the work and its flow visible to everyone.
The 6 core practices of Kanban
The Kanban Method is built on six core practices that, applied together, turn a visual board into a system for improving flow. They're meant to be adopted gradually, on top of however a team already works.
- Visualize the workflow. Put the work and its stages on a board so the whole process is visible; the foundation everything else builds on.
- Limit work in progress (WIP). Cap how many items can be in each stage at once. This is the defining practice, and the one that actually changes behavior.
- Manage flow. Watch how work moves through the system, looking for bottlenecks and delays, and smooth them out so work flows steadily.
- Make process policies explicit. Write down the rules — what "done" means for each column, how items are prioritized — so everyone shares the same understanding.
- Implement feedback loops. Use regular reviews and metrics to inspect how the system is performing and where it can improve.
- Improve collaboratively, evolve experimentally. Change the process incrementally, as a team, using evidence, applying the continuous-improvement mindset at Kanban's core.
Underpinning these practices are Kanban's change-management principles: start with what you do now, pursue incremental and evolutionary change, and respect current roles and responsibilities. This is what makes Kanban unusually easy to adopt — it doesn't demand you blow up your process and start over; it asks you to make your current process visible and improve it, one small step at a time.
WIP limits and flow
If Kanban has one signature idea, it's the work-in-progress (WIP) limit — an explicit cap on how many items the team allows in a given stage at once. When a column is full, no one pulls new work into it until something moves out. It sounds restrictive, but it's the mechanism that makes everything else work.
The logic is counterintuitive but powerful: limiting how much you start makes you finish faster. When a team works on too many things at once, everything slows down — attention fragments, items sit half-done, and work languishes in progress. By capping WIP, Kanban forces the team to finish work before starting more, embodying the mantra "stop starting, start finishing." This creates a pull system: work is pulled into a stage only when there's capacity, rather than pushed in regardless. The payoff shows up directly in cycle time — by Little's Law, lower WIP at a steady throughput means work moves through faster. WIP limits are the small constraint that produces Kanban's biggest benefit.
Kanban metrics: cycle time and throughput
Because Kanban is all about flow, it's measured with flow metrics rather than the velocity or story points common in Scrum. The key ones tell a team how quickly and predictably work moves through its system:
- Cycle time is how long an item takes to get from "in progress" to "done." Shorter, more consistent cycle times mean faster, more predictable delivery.
- Throughput is how many items the team completes in a given period, a direct measure of delivery rate.
- Work in progress is how many items are in the system at once, watched closely because it drives cycle time.
- Lead time is the total time from when a request is made to when it's delivered, the customer's-eye view.
These metrics are most powerful when visualized on a cumulative flow diagram, which plots the number of items in each stage over time. From a single chart, a team can read its WIP (the band thickness), its throughput (the slope of the done line), and its cycle time (the horizontal distance across the bands) — and spot bottlenecks the moment they start to form. Measuring flow, rather than effort, is what lets a Kanban team forecast and improve empirically.
Kanban vs. Scrum
Kanban and Scrum are the two most popular agile approaches, and teams often weigh one against the other. The core difference: Scrum organizes work into fixed sprints with defined roles, while Kanban manages a continuous flow of work with no prescribed roles or iterations.
| Kanban | Scrum | |
|---|---|---|
| Cadence | Continuous flow | Fixed-length sprints |
| Roles | No prescribed roles | Product owner, scrum master, developers |
| Change | Can be made anytime | Avoided during a sprint |
| Key constraint | WIP limits | The sprint commitment |
| Board | Persistent | Reset each sprint |
| Best suited for | Continuous, support, or varied work | Iterative product development |
The deeper distinction is in how each is adopted. Scrum is a defined framework you implement, with its roles, events, and artifacts. Kanban is an evolutionary method you overlay on whatever you're already doing, changing it gradually. Neither is universally better — Scrum suits teams building a product in planned iterations, while Kanban suits continuous or unpredictable work like support and maintenance. Many teams even combine the two into scrumban, keeping Scrum's structure while adopting Kanban's flow and WIP limits. Choosing between them is about the nature of the work, not which is more "advanced."
When to use Kanban and its benefits
Kanban is at its best for continuous, flow-based work where priorities shift and demands arrive unpredictably — support and maintenance teams, operations, and any context where forcing work into fixed iterations feels artificial. It's also ideal when a team wants to improve without a disruptive reorganization, since it starts from the current process rather than replacing it.
The benefits follow from its focus on flow and visibility. Kanban delivers flexibility, absorbing changing priorities without breaking a sprint commitment; faster flow, as WIP limits shorten cycle time and expose bottlenecks; and transparency, since the board makes the state of all work visible to everyone. It reduces the overload and context-switching that come from too much work in progress, and its built-in emphasis on incremental improvement means the process keeps getting better over time. And because it layers onto an existing workflow, it's one of the easiest agile methods to start with. The main caution is that Kanban's flexibility demands discipline — without genuine WIP limits and attention to flow, a Kanban board is just a task board that looks agile without behaving that way.
Kanban on the PMP® and CAPM® Exams
Because the current PMP exam covers agile and hybrid delivery heavily, Kanban appears as a flow-based, lean-rooted agile method. You're expected to know its essentials: visualizing work on a board, limiting work in progress, pulling work through the system, and managing flow — and to recognize how it differs from Scrum's sprint-based structure.
Situational questions tend to test the flow mindset. Watch for scenarios where a team is overloaded with too much work in progress, where delivery is slowing because everything is started but little is finished, or where continuous, unpredictable work is being forced into fixed sprints — the right answers favor limiting WIP, improving flow, and choosing a flow-based approach when the work suits it. The Kanban-versus-Scrum distinction, and the idea that WIP limits improve cycle time, are common test points. Our PMP Complete Study Guide, the most complete on the market, covers Kanban and the wider agile landscape as the exam frames them.
PMP Practice Question: Kanban
A team adopted Kanban six months ago, with WIP limits on every column of its board. Delivery has not improved: whenever a column fills to its limit, the team raises the limit "so work isn't blocked," and the limits have crept from 3 to 8 across the board. Cycle time is now worse than before the change, and leadership is questioning whether Kanban fits the team at all.
What should the project manager do next?
a) Remove the limits column by column, since they keep being hit anyway, and rely on the team's discipline to finish what it starts.
b) Hold the limits where they are and change the team's response to a full column: stop starting new work and swarm on finishing until a slot opens.
c) Return the limits to their original values gradually, one column per week, so the team adjusts to tighter constraints without disruption.
d) Track cycle time per item and review the data in a weekly flow meeting before changing how the limits are used.
Correct answer: B.
Rationale: A WIP limit only improves flow if hitting it changes behavior: a full column is the system saying stop starting, come help finish. This team has been doing the opposite — every time the signal fires, it deletes the signal by raising the number, which is exactly what the creep from 3 to 8 reveals. Holding the limits and swarming on finishing restores the pull mechanism, and nothing about the numbers needs to change first. That is also why simply lowering the limits back is the near-miss rather than the answer: without changing the team's response to a full column, tighter numbers just restart the creep, while removing limits abandons the mechanism entirely, and gathering more cycle-time data defers a fix the board's own history already justifies. To drill this kind of flow judgment, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Frequently asked questions
What is Kanban?
Kanban is a visual method for managing work as it flows through a process, aiming to deliver continuously without overloading the team. Work items are shown as cards on a board, moving through columns that represent workflow stages. The name is Japanese for "visual signal" or "card." Beyond the board, Kanban is defined by limiting work in progress and managing flow, and it's applied as an agile method for knowledge work.
Where does Kanban come from and what does it mean?
Kanban means "visual signal" or "card" in Japanese. It originated at Toyota in the 1940s and 1950s as part of the Toyota Production System, where kanban cards signaled when to replenish parts in a just-in-time, pull-based manufacturing system. Around 2007, David J. Anderson formalized the Kanban Method to apply the same principles — visual boards, WIP limits, and flow management — to software and knowledge work.
What is a Kanban board?
A Kanban board is the visual tool at the heart of Kanban: a board divided into columns representing the stages of a workflow, with each work item shown as a card that moves from left to right as it progresses. A simple board has To Do, In Progress, and Done columns. What makes it a true Kanban board rather than a plain task board is the addition of work-in-progress limits and the discipline of pulling work through it.
What are WIP limits in Kanban?
Work-in-progress (WIP) limits are explicit caps on how many items can be in a given stage at once. When a column reaches its limit, no new work is pulled in until something moves out. WIP limits are Kanban's defining practice because they force the team to finish work before starting more, which reduces overload, creates a pull system, and shortens cycle time by keeping work flowing.
What is the difference between Kanban and Scrum?
Kanban manages a continuous flow of work with no prescribed roles or fixed iterations, limiting work in progress on a persistent board and allowing change at any time. Scrum organizes work into fixed-length sprints with defined roles — product owner, scrum master, and developers — and a sprint commitment that avoids mid-sprint change. Kanban overlays onto your existing process, while Scrum is a defined framework you adopt.
Is Kanban agile? When should you use it?
Yes, Kanban is a flow-based agile method, though it also has lean and manufacturing roots. It's best for continuous, flow-based, or unpredictable work such as support and maintenance, and for teams that want to improve incrementally without a disruptive reorganization, since it starts from the current process. It's less suited to work that benefits from planned, iterative delivery, where Scrum may fit better.
Is Kanban on the PMP exam?
Yes. The current PMP exam covers agile and hybrid approaches heavily, and Kanban appears as a flow-based agile method. You are expected to know its core practices — visualizing work, limiting WIP, and managing flow — how it uses metrics like cycle time and throughput, and how it differs from Scrum, often in scenarios about overloaded teams or slowing delivery.
Is Kanban on the CAPM exam?
Yes. The CAPM covers Kanban as part of its agile content, usually a little more directly than the PMP — often testing what a Kanban board is, what WIP limits do, or how Kanban differs from Scrum. Because the CAPM is scenario-based, you should also be ready to recognize when limiting work in progress is the right way to improve a team's flow.
Burnup Chart in Agile: Example & vs. Burndown [2026]
A burnup chart plots work completed and total scope as two lines, so scope stays visible. An example, how to read it, burnup vs. burndown, and the PMP exam.
Agile Release Planning: Process & Levels [2026]
Agile release planning maps features across sprints toward a release. The planning levels, date vs. scope, how to forecast with velocity, and PMP exam tips.
Minimum Viable Product (MVP): Meaning & Examples [2026]
A minimum viable product (MVP) is the simplest usable version of a product, built to learn from customers. MVP vs. prototype, examples, and PMP exam tips.
