What Is Kanban in Simple Terms?
Kanban is a visual workflow management method that helps teams see their work, limit how much they're working on simultaneously, and continuously improve their process. Think of a board with columns (To Do, Doing, Done) and sticky notes (tasks) that move across. The key insight: by limiting work-in-progress, teams actually deliver faster because they finish tasks before starting new ones.
Kanban answers the question: 'How do we improve our existing workflow and deliver continuously without fixed iterations?'
The Philosophy: Stop Starting, Start Finishing
Kanban (看板) means 'signboard' or 'visual signal' in Japanese. It originated in Toyota's manufacturing system in the 1940s as a scheduling system for just-in-time production. The core insight: upstream processes should only produce what downstream processes need, signaled by visual cards. David J. Anderson later adapted Kanban for knowledge work in the 2000s.
Unlike Scrum, which introduces specific roles, events, and timeboxes, Kanban is evolutionary—you start with what you do now and improve incrementally. There are no sprints. Work flows continuously. You don't overhaul your process; you visualize it, limit work in progress, and improve systematically.
The Kanban Board: Visualizing Your Workflow
The Kanban board is the heart of the method. It makes invisible work visible, showing everyone what's being worked on, where bottlenecks exist, and what's completed.
Typical Board Structure
Backlog / To Do
Work waiting to be started. Items are prioritized—team members pull from the top.
In Progress / Doing
Work actively being done. This column often has WIP limits to prevent overload.
Review / Testing
Work waiting for or undergoing review, approval, or testing.
Done
Completed work that meets the Definition of Done.
Boards should reflect your actual workflow. A software team might have columns like: Backlog → Analysis → Development → Code Review → Testing → Deployment → Done. A content team might have: Ideas → Writing → Editing → Design → Published.
The 6 Core Practices of Kanban
These practices, defined by David J. Anderson, form the foundation of Kanban. Implementing all six creates a system for continuous improvement.
Visualize the Workflow
Make all work visible using a board with columns representing stages. Every work item is a card that moves from left to right. Include everything—not just planned work, but interruptions, support requests, and technical debt. Visualization exposes hidden work and competing priorities.
Limit Work in Progress (WIP)
This is Kanban's most powerful and counterintuitive practice. Set a maximum number of items allowed in each column. When a column hits its limit, no new work can enter until something moves out. This sounds like it would slow you down, but it actually speeds delivery because: (1) Team members focus on finishing rather than starting, (2) Bottlenecks become immediately visible, (3) Multitasking is eliminated—context-switching is expensive.
Manage Flow
Observe how work moves through the system. Identify where items get stuck (bottlenecks). Smooth flow is the goal—work should move steadily without long waits. Track metrics like Lead Time and Cycle Time to measure and improve. A blockeditem is a signal that something needs attention.
Make Policies Explicit
Document and share the rules governing your process: What does 'Ready' mean? What does 'Done' mean? Who can pull work into which columns? What's the priority logic? When is it okay to expedite? Ambiguity causes confusion; explicit policies enable self-organization and consistent decisions.
Implement Feedback Loops
Create regular opportunities to inspect and adapt. Kanban suggests several cadences: Daily Standup (synchronize on flow), Replenishment Meeting (decide what enters the system), Service Delivery Review (discuss completed work), Operations Review (analyze system performance), Strategy Review (align with business goals).
Improve Collaboratively, Evolve Experimentally
Use models and the scientific method to propose and test improvements. Make hypotheses: 'If we reduce the WIP limit in Development, we'll reduce Cycle Time.' Run experiments. Measure results. Adjust based on evidence, not opinions. Small, incremental changes are safer than big-bang transformations.
Understanding WIP Limits: The Power of Saying 'Not Yet'
WIP limits are the defining characteristic that separates Kanban from just having a task board. Without WIP limits, you have a to-do list; with them, you have a flow management system.
Imagine a 'Development' column with a WIP limit of 3. When 3 items are in progress, no one can start a fourth item—even if they're free. Instead, they must help clear the bottleneck: pair with a colleague, help with testing, or fix a blocked item. This is uncomfortable at first but transformative.
Why WIP Limits Work
- •Forces finishing over starting—items get completed faster
- •Exposes bottlenecks—if one column is always at its limit, that's where to focus improvement
- •Reduces multitasking and context-switching costs
- •Creates slack—team members have time to help others or improve the process
- •Makes overload visible—you can't hide an unmanageable workload
Pull vs. Push: A Mindset Shift
In traditional management, work is 'pushed' onto teams by managers: 'Here are your assignments for the week.' Teams become overloaded, work piles up, and delivery slows. In Kanban, team members 'pull' work when they have capacity. When you finish a task, you pull the next highest-priority item from the upstream column. This respects the team's actual bandwidth and creates sustainable pace.
✓ The result: Less stress, fewer context switches, faster delivery of individual items, and a culture of ownership where team members choose their work rather than having it assigned.
Key Kanban Metrics
Kanban uses flow metrics to understand and improve the system. These replace velocity-based forecasting with throughput-based forecasting.
Lead Time
Total time from when a request is made (enters the backlog) to when it's delivered. Includes all waiting time. This is what customers care about—'How long from my request to delivery?'
Cycle Time
Time from when work actively starts (leaves backlog) to when it's done. Excludes queue time. This measures your team's actual work time on an item.
Throughput
Number of items completed per time period (e.g., 15 items per week). Used for forecasting: 'At this throughput, we'll complete the 45-item backlog in about 3 weeks.'
Work Item Age
How long an in-progress item has been in the system. Aging items signal problems—they might be blocked or more complex than expected.
Pros and Cons of Kanban
Advantages
- Easy to start—overlay on existing processes without disruption
- No fixed iterations—work flows continuously
- Flexible—adapts to changing priorities instantly
- Exposes bottlenecks and inefficiencies through visualization
- Reduces overload with WIP limits
- No prescribed roles—works with existing team structures
Challenges
- •Less structure can feel chaotic for teams needing more guidance
- •Without discipline, WIP limits are ignored or too high
- •No prescribed cadence for planning and delivery
- •Forecasting is harder without sprint commitments
- •Can lead to endless refinement without regular retrospectives
- •Requires mature teams capable of self-organization
When to Use Kanban
Kanban excels in environments where work arrives unpredictably and 'Sprints' feel artificial:
Use Kanban When:
- •Support and maintenance teams handling tickets
- •Operations and IT service management
- •DevOps and continuous deployment environments
- •Content production and editorial workflows
- •Service desks and help desks
- •Personal productivity and task management
- •Teams that need to respond to emergent priorities
- •Any team that wants to improve their existing process incrementally
When Kanban May Not Be Ideal
- •Teams that benefit from the structure of fixed iterations
- •New products needing the focus of Sprint Goals
- •Organizations requiring predictable delivery dates
- •Teams that struggle with self-organization and need more framework
Real-World Example: A DevOps Team
A DevOps team handles deployments, infrastructure requests, and incident response. Work is unpredictable—a critical production issue can arrive at any moment. Sprints don't make sense because you can't delay a production outage until the next Sprint. Their Kanban board has columns: Backlog → Analysis → In Progress → Review → Deployed. WIP limits ensure no one is juggling too many tasks. When an urgent incident arrives, it's marked as an 'expedite' item (limited to 1 at a time) and gets immediate attention while regular work pauses. Lead Time metrics help them make Service Level Agreements (SLAs) with internal customers.
Key Takeaways
- 1Kanban is about flow—work moves continuously without fixed iterations
- 2Visualization makes all work visible; nothing is hidden
- 3WIP limits are the key to faster delivery—stop starting, start finishing
- 4Pull systems respect team capacity and prevent overload
- 5Flow metrics (Lead Time, Cycle Time, Throughput) guide improvement
- 6Kanban is evolutionary—start where you are and improve incrementally
