Kanban is one of the simplest ways to make work visible and improve how it flows, which is why teams in software, operations, marketing, HR and many other areas use it. It does not ask you to reorganise your team or adopt new roles. It asks you to see your work clearly, limit how much you take on at once, and keep improving. This guide explains where Kanban comes from, how it works, the practices and metrics that matter, and how to get started.
Key takeaways
- Kanban is a method for managing and improving the flow of work using a visual, pull-based system.
- Its core practices include visualising work, limiting work in progress (WIP) and actively managing flow.
- Kanban does not prescribe roles, fixed-length iterations or specific meetings; teams start with how they work today.
- Four flow measures matter most: work in progress, throughput, cycle time and work item age.
- Kanban can be used on its own or alongside Scrum.
What is Kanban?
"Kanban" is a Japanese word usually translated as "signboard" or "visual card". The idea comes from manufacturing. At Toyota, Taiichi Ohno developed a system of cards that signalled when more parts were needed, so production was pulled by actual demand rather than pushed ahead of it. This helped reduce waste and overproduction and became part of the Toyota Production System.
In knowledge work, such as software development, the approach was adapted by David J. Anderson and others in the 2000s, including through work at Microsoft and later at Corbis. Anderson's 2010 book Kanban: Successful Evolutionary Change for Your Technology Business helped establish what is often called the Kanban Method.
In 2020, Daniel Vacanti and Yuval Yeret published The Kanban Guide, a short description of Kanban that focuses on flow. It defines Kanban as a strategy for optimising the flow of value through a process using a visual, pull-based system.
Both sources are widely used. They share the same core ideas: make work visible, limit work in progress and improve flow. This guide notes where an idea comes from when it matters.
Kanban at a glance
| Aspect | Kanban |
|---|---|
| Origin | Toyota Production System; adapted for knowledge work in the 2000s |
| Core idea | Visualise work, limit work in progress, manage and improve flow |
| Roles | None required; teams keep existing roles |
| Iterations | None required; work flows continuously |
| Key tool | A Kanban board with explicit WIP limits |
| Key measures | WIP, throughput, cycle time, work item age |
| Starting point | Start with how you work today and improve step by step |
The principles of the Kanban Method
The Kanban Method, as described by David J. Anderson and colleagues, is built on principles about change and about delivering services.
Change management principles
- Start with what you do now. Kanban does not replace your current process on day one. It makes it visible first.
- Agree to pursue improvement through evolutionary change. Small, continuous improvements rather than large reorganisations.
- Encourage acts of leadership at all levels. Anyone can suggest and lead an improvement.
Service delivery principles
- Understand and focus on customers' needs and expectations.
- Manage the work, and let people self-organise around it.
- Evolve policies to improve customer and business outcomes.
The emphasis on starting with the current process is one of the main reasons teams find Kanban easy to adopt: nobody's job title changes on the first day.
The six practices of the Kanban Method
- Visualise the work. Show every piece of work and its current stage on a board, so everyone sees the same picture.
- Limit work in progress. Set a maximum number of items allowed in each stage at once. This is what turns a task board into a Kanban system.
- Manage flow. Watch how work moves, spot where it gets stuck and act to keep it moving.
- Make policies explicit. Agree and display the rules: when an item can move to the next stage, what "done" means for each stage, how urgent work is handled.
- Implement feedback loops. Review work, flow and the process regularly, through meetings often called cadences.
- Improve collaboratively, evolve experimentally. Use evidence and small experiments to improve the system together.
What The Kanban Guide says
The Kanban Guide by Daniel Vacanti and Yuval Yeret takes a more compact view. It describes three practices:
- Defining and visualising a workflow
- Actively managing items in a workflow
- Improving a workflow
It also introduces the Definition of Workflow, a shared understanding that includes what the units of value (work items) are, where work starts and finishes, the states work moves through, how WIP is controlled, explicit policies, and a Service Level Expectation: a forecast of how long a work item should take to finish.
The Kanban Guide identifies four key flow measures: work in progress, throughput, work item age and cycle time. Like the Kanban Method, it does not prescribe roles or specific events.
How a pull system works
Our guide to WIP limits explains how to set and use them.
In a traditional push system, work is assigned to people as soon as it arrives, whether or not they have capacity. The result is a lot of work started and little finished. In a pull system, new work is only started when there is capacity to take it on, usually when an item moves forward and frees up a place within the WIP limit.
Pulling work has two effects. It prevents overload, and it shortens the time each item takes, because people focus on finishing rather than starting. A common Kanban saying sums this up: stop starting, start finishing.
The Kanban board
For a step-by-step setup, see how to set up a Kanban board.
A Kanban board is the visual heart of the system. It can be a whiteboard with sticky notes or a digital tool. Common elements include:
- Columns: the stages work moves through, such as Ready, In progress, Review and Done.
- Cards: one card per work item, showing what it is and often who is working on it.
- WIP limits: the maximum number of cards allowed in a column, usually shown at the top.
- Swimlanes: horizontal rows that separate types of work, such as urgent items or different products.
- Blocker markers: a clear sign that an item is stuck and why.
- Explicit policies: short rules for each column, such as what must be true before an item can move on.
The Kanban Method also describes classes of service, which set how different kinds of work are treated. Commonly used classes include expedite for urgent work, fixed date for work with a deadline, standard for normal work and intangible for work with no immediate urgency, such as technical improvements.
Kanban metrics
Our guide to Kanban metrics explains each measure, the charts and forecasting in depth.
Kanban uses a small set of measures to understand and predict flow:
- Work in progress (WIP): the number of items started but not finished.
- Throughput: the number of items finished in a period, such as per week.
- Cycle time: how long an item takes from when work starts to when it finishes.
- Work item age: how long an item that is still in progress has been in progress. Old items are a warning sign.
Little's Law
These measures are linked by Little's Law, a result from queueing theory published by John Little in 1961. In a stable system, average cycle time equals average work in progress divided by average throughput. The practical lesson: if throughput stays the same, reducing WIP reduces cycle time. That is why limiting WIP makes work finish faster.
Charts that help
- Cumulative flow diagram (CFD): shows how many items are in each stage over time, making growing queues easy to spot.
- Cycle time scatterplot: plots the cycle time of each finished item, helping teams set realistic expectations such as "85% of items finish within 8 days".
- Monte Carlo forecasting: uses past throughput to simulate many possible futures and forecast when a batch of work is likely to be done.
Benefits of Kanban
- Visibility: everyone can see what is happening and where work is stuck.
- Faster delivery: limiting WIP shortens cycle times.
- Less overload: people take on work when they have capacity.
- Flexibility: priorities can change as soon as capacity frees up, without waiting for a new iteration.
- Easy to start: no reorganisation or new job titles are needed.
- Predictability: flow data supports realistic forecasts based on evidence.
When Kanban works best
- Work arrives unpredictably, such as support, maintenance or operations.
- Priorities change frequently.
- Teams want to improve their current process without a major change.
- Work items vary widely in size and urgency.
- Teams already use Scrum but want to improve the flow of work within Sprints.
For a detailed comparison, see Kanban vs Scrum.
How to get started with Kanban
- Map your current workflow. List the stages work actually goes through today, not an ideal process.
- Build a board. One column per stage, one card per work item.
- Put all current work on it. Include everything, even small tasks and urgent requests.
- Agree what the work items are. Decide what counts as one card, so items are roughly comparable.
- Set WIP limits. Start with a limit close to what the team handles now, then lower it gradually.
- Make policies explicit. Write short rules for when items move between columns.
- Start measuring. Record when each item starts and finishes, so you can track cycle time and throughput.
- Review and improve regularly. Hold short, regular reviews to discuss flow and try one improvement at a time.
Kanban meetings and cadences
Each cadence is explained in detail in Kanban meetings and cadences explained.
Kanban does not require any meetings, but the Kanban Method describes a set of regular reviews called cadences that support feedback loops. They include a daily Kanban meeting focused on flow, a replenishment meeting to select new work, delivery planning, a service delivery review, and wider operations, risk and strategy reviews. Teams adopt the ones that help them, at the frequency that suits their work.
Kanban with Scrum
For a detailed guide, see Kanban for Scrum Teams.
Kanban and Scrum can work together. Many Scrum Teams use Kanban practices such as visualising work, WIP limits and flow metrics within their Sprints, keeping the structure of Scrum while improving how work flows. The Scrum events and accountabilities stay in place; Kanban adds a sharper focus on flow. Our complete Scrum Master guide and Scrum events explained cover the Scrum side.
Kanban in different kinds of teams
- Software development: columns often follow the path from ready to development, review, testing and release, with WIP limits to stop work piling up in testing.
- IT support and operations: work arrives unpredictably, so continuous flow suits it well. Swimlanes or classes of service separate urgent incidents from routine requests.
- Marketing: campaigns, articles and design requests move through stages such as brief, draft, review and published, making bottlenecks in approvals easy to see.
- HR and recruitment: candidates can be tracked through stages such as screening, interview and offer, with limits that keep the team from starting more hiring processes than it can finish.
In every case, the principle is the same: map the real stages, make the work visible and limit work in progress.
A worked example: a support team adopts Kanban
As an illustration, imagine a support team that feels permanently overloaded. Requests arrive by email, chat and phone, and everyone is working on many things at once. Here is how it might adopt Kanban:
- Map the real workflow. The team agrees that requests go through New, Investigating, Waiting for customer, Fixing and Done.
- Put everything on a board. For the first time, the team sees how many requests are open at once, and that many have been sitting in Investigating for weeks.
- Add classes of service. An expedite lane for outages, and a standard lane for everything else.
- Set a WIP limit. The team limits Investigating to a number slightly below what is currently in it, and agrees to finish items before starting new ones.
- Start measuring. The team records when each request starts and finishes, and reviews cycle times weekly.
- Improve one thing at a time. The data shows many items waiting for another team's approval, so the team raises this with that team and agrees a faster route.
The point of the example is the approach: start with the current process, make it visible, limit work and use data to improve step by step.
Service Level Expectations
The Kanban Guide describes a Service Level Expectation (SLE) as part of a team's Definition of Workflow. An SLE is a forecast of how long a single work item should take from start to finish, expressed with a probability. For example, a team might say that 85% of items finish within 10 days.
An SLE is usually based on the team's own past cycle times, so it reflects reality rather than hope. It helps in two ways: customers get a realistic expectation, and the team can spot items at risk. If an item's age approaches the SLE, the team can focus on it before it becomes late.
Personal Kanban
Kanban also works for individuals. Jim Benson and Tonianne DeMaria Barry described this in their 2011 book Personal Kanban, built on two simple rules: visualise your work and limit your work in progress. A personal board with a few columns, such as To do, Doing and Done, and a small limit on Doing, can be a powerful way to manage a busy workload and finish more of what you start.
Kanban and Lean
Kanban grew out of Lean thinking, the ideas behind the Toyota Production System. Lean focuses on delivering value to the customer while removing waste, the Japanese term for which is muda. Waste in knowledge work includes work that waits in queues, work started but never finished, rework and handoffs that add delay. Lean also emphasises flow, pull and continuous improvement, often called kaizen.
Kanban puts these ideas into practice: the board makes waste visible, WIP limits create pull, and regular reviews drive continuous improvement. Lean thinking is also part of Scrum; the 2020 Scrum Guide names empiricism and lean thinking as the foundations Scrum is built on.
Common Kanban mistakes
- A board without WIP limits. Without limits, it is just a task board, and the main benefit of Kanban is lost.
- WIP limits that are never respected. A limit only helps if the team stops starting new work when it is reached.
- Designing an ideal process instead of mapping the real one. Kanban starts with what you do now.
- Hiding work. Urgent requests handled off the board make the system misleading.
- Not measuring. Without cycle time and throughput data, improvements are guesses.
- Ignoring blocked items. A blocked card is a signal to swarm the problem, not to start something else.
- Changing everything at once. Evolutionary change means one improvement at a time.
Kanban certification
If you want to build and demonstrate Kanban skills, Scrum Intelligence offers Kanban Management in Systems Plus, a professional-level certification focused on flow, WIP limits and flow metrics. The exam is taken online on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years. See the certification page for current learning paths and prices. For the wider picture of Agile approaches, read Agile vs Scrum.
Frequently asked questions
What is Kanban in simple terms?
A way of managing work by making it visible on a board, limiting how much is in progress at once, and continually improving how work flows.
Where does Kanban come from?
From the Toyota Production System, where Taiichi Ohno used cards to signal demand. It was adapted for knowledge work in the 2000s, notably by David J. Anderson.
Does Kanban have roles?
No. Kanban does not require any new roles. Teams keep their existing roles and responsibilities.
Does Kanban use Sprints?
No. Kanban has no fixed-length iterations; work flows continuously and new work is pulled when there is capacity.
What is a WIP limit?
The maximum number of work items allowed in a stage at one time. It helps teams finish work before starting more.
What are the main Kanban metrics?
Work in progress, throughput, cycle time and work item age.
Can Kanban be used with Scrum?
Yes. Many Scrum Teams use Kanban practices such as WIP limits and flow metrics within their Sprints.
Is Kanban only for software teams?
No. Kanban is used in many kinds of work, including operations, marketing, HR, support and manufacturing, where it began.
