What is Kanban?
Kanban is an agile method for visualizing and optimizing workflows. The name comes from Japanese and literally means "signal card" or "visual signal". The basic principle: Make work visible, limit the amount of work in progress, and continuously improve the flow.
Kanban was developed in the 1940s at Toyota as a system for production control. Taiichi Ohno, an engineer at Toyota, was inspired by the replenishment system of American supermarkets: products are only restocked when inventory falls below a certain threshold. This pull principle -- work is pulled, not pushed -- is the core of Kanban.
David J. Anderson adapted the Toyota system in 2007 for knowledge work and formulated the Kanban method for software development and project management. Today, Kanban is used worldwide in IT teams, marketing departments, HR, support, and many other areas.
Unlike Scrum, which introduces new roles and events, Kanban starts where the team is today. No existing processes, roles, or titles are changed. Instead, the current workflow is visualized and gradually improved. This makes Kanban particularly suitable for teams that do not want a radical overhaul.
The 4 Kanban Principles
1. Start with what you do now
Kanban does not require a revolution. You begin with your current process, visualize it on a board, and improve it step by step. There is no "Day 1" where everything is different -- Kanban is a gentle introduction to process improvement.
2. Pursue incremental, evolutionary change
Big changes create resistance. Kanban relies on small, continuous improvements (Kaizen). The team identifies bottlenecks, experiments with solutions, and adapts the process gradually -- without rebuilding the entire system at once.
3. Respect existing roles and responsibilities
Kanban does not define new roles. The team lead remains the team lead, the developer remains the developer. The existing organizational structure is respected. Changes in roles may emerge from practice but are not prescribed by Kanban.
4. Encourage leadership at all levels
Improvements should not only come "from above". Every team member is invited to recognize bottlenecks, suggest improvements, and take responsibility for the work process. Kanban fosters a culture where leadership is an activity, not a title.
The Kanban Board at a Glance
Tasks flow from left to right through defined phases — with WIP limits to prevent overload.
Kanban board with four columns and WIP limits. Tasks flow from left to right following the pull principle.
The 6 Kanban Practices
1. Visualize the workflow
The most important practice: Make all work visible. A Kanban board shows all tasks, their current status, and the flow through the process. If work is invisible, it cannot be managed. The board is not a planning tool -- it is a mirror of the real work process.
2. Limit work in progress (WIP Limits)
WIP Limits (Work in Progress) restrict how many tasks can be in a column at the same time. Why? Because multitasking increases lead time and reduces quality. When a WIP limit is reached, no new task may be started until an existing one is completed or passed on. This forces the team to finish work instead of starting new work.
3. Manage the flow
The goal is a smooth, predictable work throughput. The team observes how quickly tasks flow through the system (lead time, throughput) and optimizes the flow. Congestion in a column indicates a bottleneck -- that's where action must be taken.
4. Make process policies explicit
When is a task "done"? Who may move tasks into which column? What are the criteria for prioritization? These rules should be documented in writing and visible to all -- preferably directly on the board.
5. Implement feedback loops
Regular meetings ensure transparency and adaptation. The most important Kanban meetings: daily stand-up at the board (15 minutes), weekly Replenishment Meeting (prioritizing new tasks), and monthly Service Delivery Review (analyzing throughput and lead time).
6. Improve collaboratively, evolve experimentally
Improvements are based on data and experiments, not opinions. The team formulates hypotheses ("If we lower the WIP limit from 6 to 4, lead time will decrease"), tests them, and evaluates the results. This scientific approach prevents endless discussions and leads to measurable improvements.
Building a Kanban Board: Columns, Swimlanes, and WIP Limits
A Kanban board is the visual representation of your work process. Each column represents a status, each card a task. The board can be physical (whiteboard with Post-its) or digital (tools like Trello, Jira, PathHub AI).
Example Board: Software Team
Feature
Task
Bug
Feature
Task
Feature
Feature
Bug
Designing Columns
The board's columns represent the stages of your work process. A typical software board might look like this: Backlog, Analysis, Development, Code Review, Testing, Done. Important: Map your actual process, not an idealized one. Columns can also be split ("Development: In Progress" and "Development: Awaiting Review").
Using Swimlanes
Swimlanes are horizontal lanes that divide the board into areas. Typical applications: Swimlanes by priority (Expedite, Standard, Waiting), by task type (Feature, Bug, Technical Debt), or by team/person. Swimlanes help manage different work categories on one board.
Setting WIP Limits Correctly
The WIP limit is the most powerful tool in Kanban -- and simultaneously the one most often misused. Set too high, it loses its effect. Set too low, and the team sits idle. The art lies in finding the right balance.
WIP Limit = Number of team members x 1.5 (rounded up)
Examples:
- 3 people on the team: WIP limit = 5
- 5 people on the team: WIP limit = 8
- 8 people on the team: WIP limit = 12
This is a starting point, not a law. Observe the flow over 2-3 weeks and adjust: Does work regularly pile up? Lower the limit. Do people frequently have nothing to do? Slightly raise the limit.
WIP Limits per Column
The total WIP limit is distributed across individual columns. A team of 5 with a total WIP of 8 might distribute the limits like this:
- To Do (Ready): WIP limit 5 -- enough tasks as a buffer so nobody has to wait.
- In Progress: WIP limit 5 -- a maximum of one task per person as their main task.
- Review: WIP limit 3 -- reviews should be completed quickly so the flow does not stall.
Important: The WIP limit of the Review column is often the most critical point. If reviews pile up, it blocks the entire flow. Many teams adopt the rule: "Review takes priority over new work" -- this significantly accelerates throughput.
📋 Interactive Kanban Board
Create your own Kanban board: Add tasks and move them between columns.
0 tasks
Kanban vs. Scrum: The Key Differences
| Criterion | Kanban | Scrum |
|---|---|---|
| Cadence | Continuous flow | Fixed sprints (1-4 weeks) |
| Roles | No prescribed roles | Product Owner, Scrum Master, Developers |
| Planning | Ongoing, based on capacity (Pull) | Sprint-wise in Sprint Planning |
| Changes | Possible at any time (new cards into backlog) | Between sprints (not during a sprint) |
| Limitation | WIP Limits per column | Sprint scope (Velocity-based) |
| Metrics | Lead time, Throughput, Cumulative Flow | Velocity, Sprint Burndown, Burnup | Meetings | None prescribed (recommended: Stand-up) | 5 defined events (Sprint, Planning, etc.) |
| Introduction | Evolutionary (keep existing processes) | Revolutionary (introduce new roles and events) |
| Suitable for | Support, maintenance, operations, service teams | Product development, complex projects |
In practice, many teams use a hybrid approach, often called "Scrumban": They use a Kanban board with WIP limits but work in fixed iterations as in Scrum. This can combine the best of both worlds but requires discipline to avoid diluting the advantages of both methods.
Kanban Metrics: Lead Time, Cycle Time, Throughput
What you do not measure, you cannot improve. Kanban defines three core metrics that show you how efficiently your system is working.
Lead Time
Lead Time measures the total duration from the moment a task enters the system (Backlog) until it is finished (Done). It represents the customer perspective: How long does the requester have to wait until their request is completed?
Example: A feature request is created on Monday and delivered the following Wednesday. The Lead Time is 9 days. The goal is to reduce Lead Time and decrease its variance -- this makes delivery times predictable.
Cycle Time
Cycle Time measures only the active processing time -- from the moment someone pulls the task into "In Progress" until it is "Done." The difference between Lead Time and Cycle Time shows you the waiting time in the system. High waiting time indicates bottlenecks in backlog management or prioritization.
Throughput
Throughput indicates how many tasks are completed per time unit (day, week, month). It is the most important metric for capacity planning. If your team completes an average of 12 tasks per week and there are 36 tasks in the backlog, you know: you need approximately 3 weeks.
Kanban metrics serve process improvement, not individual performance evaluation. Use them to find bottlenecks and start experiments -- not to put pressure on individual team members. A team that fears its metrics will stop measuring them honestly.
Common Kanban Mistakes
Kanban sounds simple -- and that is exactly the trap. Many teams set up a board but ignore the crucial principles. Here are the five most common mistakes:
- 1. Not setting a WIP limit: A board without a WIP limit is not a Kanban board -- it is a to-do list with columns. Without limiting work in progress, bottlenecks, multitasking, and overload will occur. The WIP limit is not optional; it is the core principle.
- 2. Not enforcing the WIP limit: Even worse than having no limit is having one that is regularly exceeded. "Exceptions" for urgent tasks undermine the entire system. Instead, use an Expedite Lane with its own very low WIP limit (e.g., 1).
- 3. Not keeping the board up to date: If cards are not moved and statuses are inaccurate, the board loses its value as a management tool. Rule: Every status change is reflected on the board immediately -- not just at the next standup.
- 4. Not measuring metrics: Without Lead Time, Cycle Time, and Throughput, you are flying blind. You will not notice whether improvements are working or whether performance is stagnating. Even simple tracking (when was the card created, when completed?) is enough to start with.
- 5. Treating Kanban as pure visualization: Putting up a board does not make you agile. Kanban is a system of continuous improvement. If you never run feedback loops, never adjust WIP limits, and never analyze bottlenecks, you are only using 10% of its potential.
Kanban Board Examples for Different Teams
Kanban is not a one-size-fits-all solution. The column structure and rules must match the team's work process. Here are three proven board setups:
Software Development Team
A typical Kanban board for a development team of 5 people:
- Backlog (no limit) -- User stories, bugs, technical debt, prioritized by the Product Owner.
- Ready for Dev (WIP: 4) -- Stories with acceptance criteria, estimated and ready for implementation.
- In Development (WIP: 5) -- Active development. Each developer has a maximum of one story.
- Code Review (WIP: 3) -- Pull requests awaiting review. Rule: Reviews within 4 hours.
- QA / Testing (WIP: 3) -- Functional tests, regression tests, acceptance.
- Done -- Deployed and accepted.
Swimlanes: Upper lane for hotfixes (Expedite, WIP: 1), middle lane for features, lower lane for technical debt.
Marketing Team
A content marketing team of 4 people:
- Ideas / Backlog (no limit) -- Content ideas from brainstorming, SEO research, customer requests.
- Briefing (WIP: 3) -- Topic is defined; target audience, keywords, and format are set.
- In Production (WIP: 4) -- Text is being written, design is being created, video is being produced.
- Review & Approval (WIP: 2) -- Proofreading, brand check, legal approval.
- Scheduled (WIP: 3) -- Content is finished and scheduled for publication.
- Published -- Live and being monitored.
Swimlanes: By content type (Blog, Social Media, Newsletter) or by campaign.
HR / People Operations
An HR team managing recruiting processes with Kanban:
- Open Positions (no limit) -- Approved job postings.
- Sourcing (WIP: 5) -- Active search and outreach to candidates.
- Screening (WIP: 4) -- Applications are reviewed, initial interviews conducted.
- Interview (WIP: 3) -- Technical interview, trial assignment, team meeting.
- Offer (WIP: 2) -- Contract negotiation, salary alignment.
- Hired -- Contract signed, onboarding planned.
Swimlanes: By department (Engineering, Sales, Marketing) or by seniority (Junior, Mid, Senior).
Kanban for Projects: When is it the Right Choice?
Kanban is particularly suitable when the following conditions apply:
- Continuous task flow: Your team handles incoming requests, tickets, or tasks continuously -- not bundled in releases or sprints.
- Different task types: Features, bugs, support requests, and technical debt land in the same team. Kanban allows prioritization without rigid sprint boundaries.
- Optimize existing processes: The team basically functions, but throughput should be improved and bottlenecks eliminated.
- Resistance to major changes: If the organization is not ready for new roles (Scrum Master, Product Owner), Kanban offers a gentler entry.
- Service-oriented teams: IT support, DevOps, maintenance teams, and customer support particularly benefit from the Kanban method.
Kanban is less suitable if you are developing a new product and need regular, predictable releases. In this case, Scrum is often the better choice. For projects with a clearly defined scope and regulatory requirements, a classic project plan may be more sensible.
Digital Kanban Tools
A physical board on the wall has its charm -- but for distributed teams and long-term tracking, there is no way around digital tools. The most common Kanban tools in 2026:
- Trello: The classic for simple Kanban boards. Intuitive, free for small teams, limited automation.
- Jira: The standard in software development. Powerful but with a steep learning curve. Kanban and Scrum boards, extensive metrics.
- Asana: Board view for Kanban, plus lists and timeline. Well-suited for non-developer teams.
- Monday.com: Flexibly customizable, good visualizations, but quickly expensive for larger teams.
- Notion: Database-based boards that can be used for Kanban. Flexible, but not a dedicated Kanban tool.
However: Kanban tools manage execution -- they do not help with planning. Before you fill your board with tasks, you need a structured project plan. And this is exactly where PathHub AI comes in.
PathHub AI generates a structured project plan with phases, tasks, and milestones in seconds. The AI automatically identifies stakeholders, detects risks, and suggests realistic timelines. The generated tasks can be transferred directly as Kanban cards to your board. This way, you do not start with an empty board but with a well-thought-out plan.
Kanban shows the status -- PathHub AI plans the project.
Kanban and AI: How PathHub AI Supports Agile Planning
Even though Kanban focuses on a continuous flow, every project needs overarching planning: What tasks are there? How are they related? What is the timeframe? What is the budget? This is exactly where PathHub AI supports.
- Generate tasks: Describe your project, and PathHub AI creates a structured task list -- the perfect foundation for the Kanban backlog.
- Phases as swimlanes: The AI-generated project phases can serve as swimlanes on the Kanban board to separate different work areas.
- Time estimation and prioritization: The AI estimates duration and effort per task -- helpful information for prioritization and capacity management.
- Budget and resources: PathHub AI provides budget estimates per phase, serving as a guide for resource planning.