What is the kanban methodology?
Kanban is a workflow management method that visualizes work, limits work in progress, and optimizes the flow of tasks through a defined process. Originally developed for manufacturing at Toyota in the 1940s, kanban was adapted for knowledge work - particularly software development - in the mid-2000s by David J. Anderson. The method has since become one of the most widely used approaches to software project management, especially among teams practicing continuous delivery.
At its core, kanban answers a simple question: what is everyone working on right now, and what should they work on next? The answer lives on a shared board - a visual representation of your workflow where every piece of work is a card and every stage is a column. When you look at the board, you see the full state of the project without asking anyone for a status update.
Unlike scrum, which imposes structure through sprints, ceremonies, and roles, kanban starts from where you are. You map your existing workflow onto the board, make the implicit rules explicit, and then improve incrementally. There is no "kanban transformation" - there is just making work visible and then removing the friction you can now see.
What are the five core principles of kanban?
Kanban rests on five foundational principles. Each one builds on the previous, and skipping any of them undermines the entire system. Teams that adopt kanban boards without the underlying discipline often end up with a pretty task list that provides no more value than a spreadsheet.
1. Visualize all work
Every task, bug, feature, spike, and ad-hoc request must exist as a card on the board. If a piece of work is not on the board, it does not exist as far as the team is concerned. This is the most fundamental principle and the one most teams violate first - someone picks up a "quick fix" without creating a card, and suddenly the board no longer reflects reality.
Visualization serves two purposes. First, it gives the team shared situational awareness - everyone can see what is in progress, what is blocked, and what is next. Second, it makes hidden work visible. Most teams are surprised by how much untracked work they carry: Slack requests, ad-hoc debugging sessions, impromptu architecture discussions that turn into three-day detours. Putting all of it on the board reveals your team's true workload.
2. Limit work in progress
WIP limits are the single most important kanban practice. A WIP limit caps how many cards can exist in a given column at the same time. If your "In Progress" column has a WIP limit of three and there are already three cards there, no one can start a new task until one moves forward.
This feels constraining. That is the point. Without WIP limits, developers start new tasks whenever they feel like it, and the board fills with half-finished work. Context switching between five active tasks destroys productivity - research consistently shows that each additional concurrent task reduces effective throughput on all of them. WIP limits force completion: finish what you started before starting something new.
When all WIP slots are full, team members are forced to do the next most valuable thing: help unblock existing work. Review a PR, pair on a stuck problem, write the tests someone skipped. This is the behavior change that makes kanban effective - not the board itself, but the discipline of finishing over starting.
Start with a WIP limit equal to the number of developers on the team. After two weeks, tighten it by one. Keep tightening until you feel the constraint pushing you toward healthier behavior.
3. Manage and measure flow
Flow is the rate at which cards move from the leftmost column (Backlog or To Do) to the rightmost column (Done or Deployed). The two key metrics are cycle time (how long a single card takes from start to finish) and throughput (how many cards the team completes per unit of time).
Optimizing flow means reducing cycle time without sacrificing quality. The biggest cycle time killers are wait states - a card sitting in "Code Review" for two days because no one has reviewed it, or a card blocked on a design decision that takes a week to resolve. When you can see these wait states on the board (cards not moving), you can address them directly instead of discovering the delay after the fact.
4. Make process policies explicit
Every column on the board should have a clear definition of what "done" means for that stage. What does it take for a card to move from "In Progress" to "Review"? A working implementation with tests? Just the code, no tests? A draft PR? If the team does not agree on this, cards move at different thresholds, and the board becomes unreliable.
Explicit policies also cover who can pull work, how priority is determined, and what happens when a card is blocked. Writing these down - even informally in the board description - prevents the silent disagreements that cause friction in teams.
5. Pursue continuous improvement
Kanban does not have a prescribed retrospective ceremony, but it absolutely requires regular reflection. Review your flow metrics weekly or biweekly. Look for patterns: are cards piling up in a specific column? Is cycle time trending up? Are certain types of work (bugs vs. features) moving at different speeds?
Each observation leads to a small experiment. If cards pile up in Review, try a policy that reviewers must clear the review queue before starting new work. If cycle time spikes on large features, try breaking them into smaller cards. Kanban improvement is incremental and data-driven - not a quarterly reorganization.
How does kanban differ from scrum?
Kanban and scrum are both agile methods, but they solve different problems. Understanding the differences helps you choose the right approach - or combine elements of both.
| Dimension | Kanban | Scrum |
|---|---|---|
| Cadence | Continuous flow | Fixed-length sprints (1-2 weeks) |
| Roles | None prescribed | Product Owner, Scrum Master, Dev Team |
| Meetings | None required | 4 per sprint (planning, standup, review, retro) |
| Work constraint | WIP limits per column | Sprint commitment |
| Change policy | New items added anytime | Changes wait for next sprint |
| Estimation | Optional | Story points or hours per sprint |
| Best for | Continuous delivery, ops, mixed work | Cadenced releases, stakeholder demos |
The most important difference is how each method handles new work. In scrum, incoming requests wait for the next sprint planning session. In kanban, new items can be added to the backlog at any time and pulled when capacity opens up. This makes kanban significantly more responsive to urgent bugs, customer escalations, and shifting priorities - which is why DevOps teams, support-facing engineers, and infrastructure teams almost universally prefer it.
Many teams run a hybrid: biweekly planning meetings for prioritization (borrowed from scrum) with continuous flow and WIP limits (borrowed from kanban) during the work period. This gives stakeholders the cadenced touchpoints they want while preserving the team's ability to respond to change. For more on this hybrid approach and when to use sprints, see our sprint planning guide.
When should your team use kanban?
Kanban is the right choice when one or more of the following conditions apply to your team:
- Continuous deployment. If your team ships to production multiple times per day (or wants to), batching work into sprints adds artificial delay. Kanban lets you deploy as soon as a card reaches Done.
- Mixed workloads. Teams that handle both planned features and unplanned work (bugs, incidents, support escalations) struggle with sprint commitments because unplanned work blows the forecast. Kanban accommodates both work types by managing capacity through WIP limits rather than sprint scope.
- Small teams. Teams of two to five people rarely benefit from the ceremony overhead of scrum. Sprint planning, standup, review, and retro consume four to six hours per sprint for a team that could just look at the board and talk when they need to.
- Low tolerance for process. Some teams - particularly experienced senior engineers - resist prescribed processes. Kanban's lack of mandatory ceremonies and roles means it is adopted by doing the work, not by following a framework.
- Service and operations teams. Infrastructure, SRE, and platform teams handle a stream of incoming requests with varying priority. Kanban's pull-based model - take the next highest-priority item when you have capacity - is the natural fit.
How do you set up a kanban board in practice?
Setting up a kanban board takes less than ten minutes. Getting the team to use it with discipline takes longer, but the initial setup is simple.
Step 1: Map your workflow to columns
Start by listing the stages work passes through on your team. For a typical software team, this looks like:
- Backlog - prioritized list of upcoming work. Not a dumping ground; items here should be actionable and roughly scoped.
- In Progress - a developer is actively writing code. This is where WIP limits matter most.
- Review - code is written, a pull request is open, waiting for peer review.
- Done - merged, deployed, and verified. Mark this as your Done column in Flux board settings so the system can track cycle time and auto-complete due dates.
Use a kanban board template to skip the blank-board problem and start with a proven column structure. Resist the urge to add more columns on day one. "Design", "QA", "Staging", "Product Review" - these all make sense for some teams, but start simple and add columns only when you observe a recurring bottleneck that a new column would surface.
Step 2: Set WIP limits
Start with a WIP limit of N-1 on your "In Progress" column, where N is the number of developers. For a team of four, set the limit to three. This ensures that at least one person is always free to help unblock others or review PRs. Leave the Backlog and Done columns unlimited.
Step 3: Create cards for everything
Populate the board with your current work. Every feature, bug, chore, and investigation gets a card. Use labels for categorization (bug, feature, tech debt) and assignees for ownership. If a task does not have a card, it does not exist.
Step 4: Pull, don't push
The pull model is central to kanban. When a developer finishes a card and has capacity, they pull the next highest-priority card from Backlog. No one assigns work to them; they choose the most important available item. This creates ownership and avoids the bottleneck of a single person deciding who works on what.
Step 5: Review and adapt
After one to two weeks, review the board as a team. Where did cards pile up? Which column became a bottleneck? Were WIP limits respected, or did people bypass them? Adjust column structure, WIP limits, and policies based on what you observe. Repeat every two weeks until flow feels smooth.
What are the most common kanban mistakes?
Teams adopting kanban frequently make these mistakes. Knowing them upfront saves weeks of frustration.
- No WIP limits. A kanban board without WIP limits is just a task list with columns. The limits are the mechanism that creates flow. Without them, work piles up, context switching increases, and cycle time balloons.
- Using the board as a project plan. The board reflects current state, not a plan. Putting 50 cards in the Backlog with target dates does not make it a project plan - it makes it a neglected spreadsheet with a nicer UI. Keep the Backlog lean: 10-15 items, prioritized, ready to pull.
- Ignoring blocked work. When a card cannot move forward (waiting on external dependency, blocked by another team, missing design spec), it should be flagged and discussed immediately - not left in place making the board look busier than it is.
- Tracking work outside the board. Side channels - Slack threads, email chains, mental notes - undermine the board's accuracy. If someone asks "what's the status?" and the answer requires checking Slack instead of the board, the board has failed.
- Too many columns. Every column is a potential wait state. A board with eight columns creates seven handoff points, each one a place where work can stall. Start with three to four columns and add more only when data shows a bottleneck.
For a broader comparison of methodologies and when kanban is the clear winner, see our project management guide. If you are evaluating how to track progress across multiple boards without resorting to status meetings, the project tracking guide covers multi-board views and async workflows.