Kanban: The Visual Workflow Method for Continuous Delivery
Kanban is a visual workflow management method where work items move across a board through columns representing stages like 'to do,' 'in progress,' and 'done.' Teams pull new work only when capacity opens up, governed by work-in-progress (WIP) limits. This pull-based system surfaces bottlenecks, reduces multitasking, and promotes continuous delivery without requiring fixed-length iterations or sprints.
Overview
Kanban is a method for managing the flow of work by making it visible, limiting how much work happens at once, and continuously improving the system that produces outcomes. At its core, it replaces push-based planning ("here's what you must finish this sprint") with pull-based flow ("take the next item only when you have capacity"). The result is a system that adapts to changing priorities without requiring teams to wait for a planning boundary or renegotiate commitments mid-cycle.
The method originated in Toyota's manufacturing system during the late 1940s and 1950s, where engineer Taiichi Ohno developed a signal-card system (the Japanese word "kanban" translates roughly to "visual signal" or "signboard") to synchronize production with actual demand. Rather than building inventory based on forecasts, factory workers would send a card upstream to request more parts only when their station needed them. This just-in-time approach eliminated overproduction, reduced waste, and exposed inefficiencies that had been hidden by excess inventory.
In 2007, David J. Anderson adapted these manufacturing principles for knowledge work, formalizing what became known as the Kanban Method for software development and, eventually, any kind of project work. Anderson's insight was that the same physics applies: knowledge workers drown in context-switching when they juggle too many tasks, just as a factory floor chokes when overloaded with work-in-progress. His book, "Kanban: Successful Evolutionary Change for Your Technology Business" (2010), codified the method's core practices: visualize work, limit WIP, manage flow, make policies explicit, implement feedback loops, and improve collaboratively.
What distinguishes kanban from other agile and lean approaches is its commitment to evolutionary change. Scrum prescribes roles (Scrum Master, Product Owner), ceremonies (sprint planning, retrospectives), and timeboxes (two-week sprints). Kanban prescribes almost nothing about your existing structure. You start with what you do now, visualize it, and then improve incrementally. There are no mandatory role changes, no required meeting cadences, no sprint boundaries. This makes kanban uniquely approachable for teams that cannot or do not want to reorganize around a framework, and it makes kanban a natural complement to other methods rather than a replacement.
Over the past fifteen years, kanban has evolved well beyond its software development roots. Marketing teams use it to manage campaign workflows. Operations teams track support tickets through triage and resolution. Hardware teams coordinate design reviews and manufacturing handoffs. The method scales up through portfolio kanban boards that visualize initiatives across departments, and scales down to personal productivity boards for individual contributors. The Kanban University community has formalized maturity models and advanced practices like kanban flight levels, service classes, and Monte Carlo forecasting, but the entry point remains disarmingly simple: a board, some columns, some cards, and an agreement to stop starting and start finishing.
Kanban benefits teams most when work arrives unpredictably, priorities shift frequently, and the cost of context-switching is high. Support engineering teams, platform teams handling cross-cutting requests, and product teams running continuous discovery all tend to find kanban more natural than iteration-based methods. It also works well for teams that ship continuously (deploying multiple times per day) because the method optimizes for throughput and cycle time rather than batch delivery at sprint boundaries. Hamster provides a workspace where teams can run kanban with AI agents that help track flow metrics and surface bottlenecks automatically.
The most common misunderstanding about kanban is that it is simply "a board with columns." A Trello board with no WIP limits, no flow metrics, and no feedback loops is not kanban. It is a task list with a spatial layout. The board is necessary but not sufficient. The method lives in the constraints you place on the board, the data you collect about how work flows through it, and the conversations you have about what the data reveals.
How It Works
Step 1: Map Your Current Workflow
Before creating any board, observe and document how work actually flows through your team today. Interview team members about what happens after a request arrives: who receives it, what decisions are made, what handoffs occur, and where items tend to wait. Write down the stages as verbs or statuses ("Triaged," "In Design," "In Development," "In Review," "Deployed") rather than departments or people. Be honest about the real process, not the one you wish you had. A common mistake is designing an aspirational board that nobody follows, which guarantees the board becomes stale within weeks. You know you've done this step well when a new team member could read the map and roughly predict the journey of a work item from arrival to completion.
Step 2: Design the Board
Translate your workflow map into columns on a physical or digital board. Each column represents a stage in the process. Add a backlog or input queue on the left and a done column on the right. For stages that involve distinct activities (such as "Development" having both active coding and code review), split them into sub-columns to make waiting time visible. Keep the board as simple as possible at first. Five to seven columns is typical for a team-level board. Resist the urge to model every edge case on day one. The board will evolve as you learn. For detailed guidance on board design, column structure, and card anatomy, see the [designing kanban boards](/skills/designing-kanban-boards) skill.
Step 3: Populate the Board with Current Work
Put every piece of active work on the board, not just the work you want to acknowledge. Include the half-finished tasks, the "I'll get to it next week" items, and the things waiting on external dependencies. Each card should include enough context for any team member to understand what the item is and what stage it is in: a short title, the requester or customer, and any relevant deadline. This step often produces an uncomfortable moment of clarity. Teams routinely discover they have 30 or 40 items "in progress" across 5 people, which immediately explains why nothing seems to finish. That discomfort is the point. It is the starting data for every improvement that follows.
Step 4: Set Initial WIP Limits
Assign a maximum number of items allowed in each active column. A reliable starting heuristic is to set the WIP limit per column to the number of people who work in that stage, then subtract one. So a team of four developers might set the "In Development" WIP limit to three. This feels uncomfortably tight, and that is intentional. The limit should create a small amount of productive tension that forces the team to finish items before starting new ones. You can adjust limits up or down after a few weeks of observation, but err on the side of too tight rather than too loose. A WIP limit that is never hit is not a limit. For deeper guidance, see [setting WIP limits](/skills/setting-wip-limits).
Step 5: Define Pull Policies and Entry Criteria
Document the rules that govern how items move between columns. When can a developer pull an item from "Ready for Dev" into "In Development"? What information must be present on the card? What does "done" mean for each stage? Write these policies directly on the board or in an easily accessible team document. Start simple: even a one-sentence definition of done per column is better than nothing. The goal is to eliminate ambiguity that causes rework and disagreement. For example, if "In Review" requires a pull request with passing tests and a reviewer assigned, make that explicit. Teams that skip this step often discover inconsistent quality and frequent back-and-forth between stages. See [creating pull policies](/skills/creating-kanban-pull-policies) for worked examples.
Step 6: Establish Feedback Cadences
Decide which regular meetings the team will hold and how frequently. ") and a weekly or biweekly replenishment meeting where the team decides which items to pull into the board from the broader backlog. Avoid the common mistake of turning the standup into a status report to management. The standup should be a peer coordination mechanism focused on the board itself: walking the board from right to left, identifying stuck items, and swarming on blockers. Over time, consider adding a service delivery review (monthly, examining flow metrics and trends) and a retrospective. See [running kanban cadences](/skills/running-kanban-cadences) for a detailed breakdown of each ceremony.
Step 7: Measure Flow and Iterate
Begin tracking cycle time, throughput, and work item age from day one, even if the data feels noisy. Cycle time tells you how long items take from commitment to completion. Throughput tells you how many items the team finishes per week. Work item age flags items that have been in progress too long and may be stuck or blocked. Review these metrics in your service delivery review and use them to drive experiments: "Our average cycle time spiked last month. We think it is because code reviews are taking three days. " Measure the result, keep it if it works, revert if it doesn't. This step is continuous and never finished. See [measuring flow metrics](/skills/measuring-kanban-flow-metrics) for guidance on which metrics to track and how to interpret them.
When to Use
- When your team handles a continuous stream of incoming requests that vary in size, urgency, and type, such as a support engineering team receiving bug reports, infrastructure requests, and escalations from multiple internal customers simultaneously. Kanban's pull-based model lets the team absorb variability without the overhead of sprint planning and re-planning.
- When work items arrive unpredictably and priorities shift frequently, making it impractical to commit to a fixed scope two weeks in advance. Product teams running continuous discovery, where learnings from one experiment immediately change what to build next, often find kanban's flow-based approach more natural than timeboxed iterations.
- When you need to reduce cycle time and get work delivered faster without adding headcount. Kanban's WIP limits and flow metrics systematically expose where work stalls, letting teams address root causes rather than adding more people to an already-overloaded process.
- When you are introducing process improvement to a team that is skeptical of or exhausted by methodology changes. Because kanban starts with the current process and evolves incrementally, it meets less resistance than frameworks that require role changes, new ceremonies, or restructured teams.
- When multiple teams or departments need a shared view of how work flows across organizational boundaries. Portfolio-level kanban boards can visualize initiatives from intake through delivery across product, design, engineering, and operations, revealing cross-team dependencies and handoff bottlenecks that per-team tools hide.
- When your team ships continuously, deploying multiple times per day, and the concept of a two-week sprint boundary feels artificial. Kanban optimizes for continuous delivery by treating every completed item as independently releasable, aligning the process model with the deployment reality.
When Not to Use
- When your team is new to any form of structured workflow management and needs guardrails to build discipline. Kanban's permissiveness (no mandatory roles, no mandatory ceremonies, no mandatory timeboxes) can leave inexperienced teams adrift. Scrum's prescriptive structure often serves better as training wheels because it forces teams to plan, review, and retrospect on a fixed cadence until those habits become natural.
- When stakeholders require predictable, date-based commitments for large batches of scope, such as a regulatory deadline that demands features A through F delivered together by March 15. Kanban excels at optimizing throughput and cycle time for individual items, but it does not natively produce the kind of fixed-scope, fixed-date plan that some business contexts demand. Teams in this situation often need iteration-based planning or a hybrid approach.
- When the work is genuinely sequential and single-threaded, with only one or two items in flight at any time. A solo freelancer working on one client project at a time gets little value from WIP limits and flow metrics because there is nothing to limit and nothing to measure. The overhead of maintaining a kanban system exceeds the benefit.
- When the team's biggest problem is not flow but alignment on goals, priorities, or strategy. Kanban optimizes the how of delivery, not the what. If the team is building the wrong things efficiently, adding a kanban board makes the wrong things move faster. In this case, methods focused on prioritization, like [RICE](/methods/rice-framework) or opportunity-solution trees, address the root problem.
- When deep collaboration on a single deliverable is the primary work mode, such as a three-person design team co-creating one brand identity over six weeks. Kanban's card-per-item model assumes work can be decomposed into discrete, independently movable items. Highly collaborative, entangled work does not decompose cleanly, and forcing it onto a board creates artificial fragmentation.
Examples
Example: SaaS Support Engineering Team Reducing Response Time
A 6-person support engineering team at a B2B SaaS company was handling roughly 80 tickets per week across bug fixes, infrastructure requests, and customer escalations. Average resolution time was 9 days, and the team felt perpetually overwhelmed despite working long hours. They mapped their workflow (Triage, Investigation, Fix in Progress, In Review, Deployed) onto a kanban board and discovered 34 tickets were "in progress" simultaneously. They set WIP limits of 2 per person across active columns (12 total for the team). The first two weeks were painful because developers had to help unblock stuck items instead of picking up new tickets. 5 days and the team reported feeling less stressed despite handling the same volume. The key lesson was that the bottleneck was in the Review column, not in engineering capacity. Once they added a policy that reviews must happen within 4 hours, flow improved dramatically.
Example: Startup Product Team Replacing Sprints with Flow
A 4-person product team at a seed-stage startup had been running two-week sprints but found that priorities changed almost daily based on customer feedback and founder decisions. Sprint planning felt like fiction because 60% of committed items were replaced mid-sprint. They switched to a kanban board with columns for Discovery, Ready, In Build, In QA, and Shipped, with a WIP limit of 3 in Build and 2 in QA. The product manager ran a weekly replenishment meeting to decide what to pull from the backlog, replacing the sprint planning ceremony entirely. " They kept a weekly retrospective from Scrum because they found value in it. The tradeoff was that the founder initially missed the sprint commitment as a forcing function for delivery dates, which they addressed by using cycle time percentiles to give probabilistic delivery estimates.
Example: Marketing Team Managing Campaign Workflows
A 5-person marketing team at a mid-market e-commerce company was managing content production, paid campaigns, and email sequences across spreadsheets and Slack threads. Work frequently fell through the cracks because nobody had a shared view of who was working on what. They created a kanban board with columns for Requested, Briefed, In Production, In Review, Scheduled, and Live. Each card represented a single deliverable (a blog post, an ad set, an email sequence). WIP limits were set at 3 for In Production and 2 for In Review. Within a month, the team noticed that the In Review column was consistently full because the marketing director was the bottleneck reviewer. They responded by distributing review authority: any senior team member could approve content for channels they owned. Campaign lead time dropped from 18 days to 11 days, and the number of missed deadlines fell from roughly 4 per month to fewer than 1. The biggest surprise was that the board surfaced how much unplanned work (ad-hoc requests from sales) was consuming capacity. They added a dedicated "Expedite" swimlane with a WIP limit of 1 to make that cost visible.
Example: Enterprise Platform Team Using Portfolio Kanban
A platform engineering organization of 40 people across 5 teams at a financial services company needed visibility into how strategic initiatives flowed from approval through delivery. Individual teams ran their own kanban boards effectively, but leadership had no way to see cross-team dependencies or which initiatives were stuck in handoffs. They created a portfolio-level kanban board with columns for Proposed, Committed, In Flight, and Delivered, where each card represented an initiative spanning multiple teams. WIP limits at the portfolio level were set to 8 initiatives In Flight across all 5 teams. This immediately revealed that 14 initiatives were simultaneously in flight, explaining why nothing seemed to finish. Over two quarters, leadership reduced active initiatives to 8, which felt counterintuitively slow but resulted in 40% faster average delivery time per initiative. The most important learning was that portfolio-level WIP limits required executive buy-in, because saying "no" or "not yet" to 6 initiatives meant difficult conversations with senior stakeholders. Those conversations were productive precisely because the board made the capacity constraint visible and data-driven rather than political.
Skills in This Method
Managing Projects with Kanban
How to apply Kanban principles to plan, execute, and deliver projects using pull-based scheduling and continuous delivery instead of fixed sprints.
Running Kanban Cadences and Feedback Loops
How to facilitate the seven Kanban cadences — including standups, replenishment meetings, delivery planning, and service delivery reviews — to enable continuous improvement.
Setting and Enforcing Work-in-Progress Limits
How to determine optimal WIP limits for each workflow stage to reduce bottlenecks, improve flow, and prevent team overload.
Designing Effective Kanban Boards
How to structure columns, swimlanes, and card layouts on a Kanban board to accurately visualize your team's workflow from intake to completion.
Measuring Kanban Flow Metrics
How to track and interpret lead time, cycle time, throughput, and cumulative flow diagrams to continuously improve delivery performance.
Creating Explicit Pull Policies and Workflow Rules
How to define clear entry and exit criteria for each Kanban column so the team knows exactly when and how to pull work forward through the system.
Comparing Kanban and Scrum for Your Team
How to assess the differences between Kanban's continuous flow and Scrum's sprint-based approach to choose or combine the right method for your context.
Choosing the Right Kanban Tools and Software
How to evaluate and select digital Kanban tools like Trello, Jira, and Asana based on team size, workflow complexity, and integration needs.