Kanban Method: Continuous Flow and WIP Limits
Kanban is an Agile method based on continuous flow of work, without time-boxed iterations. Originated from the Toyota production system, Kanban focuses on visualization, WIP limitation (Work In Progress) and flow optimization.
🎯 What You'll Learn
- The 4 fundamental principles of Kanban
- The 6 Kanban practices (visualization, WIP limits, flow management)
- How to create and use an effective Kanban board
- WIP limits: what they are and how to determine them
- Flow metrics: Lead Time, Cycle Time, Throughput
- Cumulative Flow Diagram (CFD) to identify bottlenecks
- Kanban vs Scrum: differences and when to use each
Origins of Kanban
Kanban (看板, literally "signboard" in Japanese) was born in the 1940s at Toyota as a Just-In-Time (JIT) production management system. The goal: produce only what's needed, when it's needed, reducing waste and inventory.
🏭 From Manufacturing to Software
In 2004, David J. Anderson adapted Kanban for software development, introducing concepts like WIP limits, flow metrics and evolutionary continuous improvement.
- 2004: Anderson applies Kanban at Microsoft
- 2007: First documented Kanban System at Corbis
- 2010: Book "Kanban: Successful Evolutionary Change for Your Technology Business"
- Today: Kanban widely adopted in Agile and DevOps
The 4 Fundamental Principles of Kanban
Core Principles
🔵 1. START WITH WHAT YOU DO NOW
└─ No revolution needed: start with current process
🔵 2. AGREE TO PURSUE INCREMENTAL, EVOLUTIONARY CHANGE
└─ Small, continuous changes (no big bang)
🔵 3. RESPECT CURRENT ROLES, RESPONSIBILITIES & TITLES
└─ No drastic organizational change required
🔵 4. ENCOURAGE ACTS OF LEADERSHIP AT ALL LEVELS
└─ Anyone can propose improvements🌱 Evolutionary Approach
Unlike Scrum (which requires specific roles and fixed ceremonies), Kanban is evolutionary: it applies on top of existing process and improves gradually.
Example:
- Team already works with ad-hoc processes? → Map current flow, visualize on board
- After 2 weeks: Introduce WIP limit on "In Progress" (e.g: max 5 tasks)
- After 1 month: Add "Code Review" column to make that step explicit
- Continuous: Measure lead time, identify bottlenecks, adapt
The 6 Kanban Practices
1. Visualize the Workflow
Make work and its flow explicit and visible to everyone through a Kanban board.
Example: Kanban Board for Dev Team
KANBAN BOARD - Software Development
┌────────────┬────────────┬────────────┬────────────┬────────────┬────────────┐
│ BACKLOG │ TO DO │IN PROGRESS │CODE REVIEW │ TESTING │ DONE │
│ │ │ (WIP: 5) │ (WIP: 3) │ (WIP: 4) │ │
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
│ │ │ │ │ │ │
│ [Story 50] │ [Story 12] │ [Story 8] │ [Story 5] │ [Story 3] │ [Story 1] │
│ [Story 51] │ [Story 13] │ [Story 9] │ [Story 6] │ [Story 4] │ [Story 2] │
│ [Story 52] │ [Story 14] │ [Story 10] │ [Story 7] │ │ │
│ ... │ │ │ │ │ │
│ │ │ │ │ │ │
│ 100+ items │ 10 items │ 3 items │ 3 items │ 2 items │ 25 items │
└────────────┴────────────┴────────────┴────────────┴────────────┴────────────┘
🔴 WIP LIMIT VIOLATED: "Code Review" has 3/3 items → BLOCKED!
⚠️ Team must complete reviews before pulling new work✅ Good Board
- Columns reflect real flow
- WIP limits visible
- Cards with essential info
- Blockers highlighted (🚫)
- Swimlanes for priority/type
- Updated in real-time
❌ Ineffective Board
- Generic columns (To Do/Done)
- No WIP limits
- Cards without details
- Blockers hidden
- Doesn't reflect reality
- Never updated
2. Limit Work In Progress (Limit WIP)
The most important Kanban concept: limit the number of tasks that can be "in progress" simultaneously in each column.
🎯 Why Limit WIP?
- Focus: Less multitasking = more concentration
- Quality: Work completed better instead of started and abandoned
- Throughput: Paradoxically, limiting WIP increases output (Little's Law)
- Bottleneck visibility: When column is full, problem becomes visible
- Collaboration: Team helps "empty" full columns (swarming)
How to Determine WIP Limit
📊 METHODS TO CALCULATE WIP LIMIT
🔵 METHOD 1: Number of People
WIP limit = Number of people × 1.5
Ex: Team of 5 people
- In Progress WIP = 5 × 1.5 = 7-8 max tasks
🔵 METHOD 2: Start Conservative
WIP limit = Number of people ÷ 2
Ex: Team of 6 people
- In Progress WIP = 6 ÷ 2 = 3 tasks (very tight!)
- Adjust if team gets blocked too often
🔵 METHOD 3: Current State + Reduce
1. Count how many tasks are typically "in progress"
2. Reduce by 20-30%
3. Monitor and adapt
Ex: Average 12 tasks in progress
- Set WIP limit = 8-10
- Observe effects on lead time
🔴 GOLDEN RULE: Start low, adjust up
Better to start with WIP limit too low and raise it
than vice versa (high limits = status quo)⚠️ WIP Limit Violated: What to Do?
Scenario: "Code Review" column has WIP limit 3 and is full.
❌ DON'T: Ignore the limit and add more tasks
✅ DO:
- Stop the Line: Don't pull new work into that column
- Swarming: Team collaborates to empty the column (everyone does code review)
- Identify Bottleneck: Why does that column fill up? (e.g: single code reviewer?)
- Address Root Cause: Corrective action (e.g: train more reviewers)
3. Manage Flow
Monitor and optimize the flow of work through the system. Goal: smooth, predictable flow without accumulations or blocks.
🌊 Characteristics of Good Flow
- Smooth: Work moves constantly, not in bursts
- Predictable: Consistent lead time
- Fast: Minimize time from request to delivery
- No blockers: Impediments removed quickly
Problematic Flow Indicators
🚨 RED FLAGS
❌ QUEUE BUILDUP
Column always full, tasks accumulate
└─ Bottleneck! Increase capacity or reduce upstream WIP
❌ FREQUENT BLOCKERS
Tasks blocked (🚫) for days
└─ Unmanaged dependencies, slow decisions
❌ INCREASING LEAD TIME
Average time to complete tasks increases over time
└─ System is slowing down, technical debt?
❌ "SKIPPED" WORK
Tasks skip columns (e.g: To Do → Done without Code Review)
└─ Board doesn't reflect real process
✅ GOOD FLOW INDICATORS
✅ Work moves steadily left-to-right
✅ Lead time stable or decreasing
✅ WIP limits respected
✅ Consistent throughput (e.g: 10 tasks/week)4. Make Policies Explicit
Clearly define the rules for when a task can move from one column to another (Definition of Done for each step).
Example: Transition Policies
📋 PULL POLICIES (When can I move a card?)
To Do → In Progress:
✅ Clear acceptance criteria
✅ Dependencies resolved
✅ Assigned to developer
✅ WIP limit "In Progress" not reached
In Progress → Code Review:
✅ Code compiles without errors
✅ Unit tests written and passing
✅ Self-review completed
✅ WIP limit "Code Review" not reached
Code Review → Testing:
✅ At least 2 reviewers approved
✅ All comments resolved
✅ Merged to main branch
✅ WIP limit "Testing" not reached
Testing → Done:
✅ Test plan executed
✅ No P0/P1 bugs open
✅ Product Owner accepted
✅ Deployed to staging5. Feedback Loops
Implement regular feedback loops for inspection and adaptation of the system.
🔄 Kanban Meetings
- Daily Standup: 15 min, walk the board right to left
- Replenishment: When to add tasks to board (e.g: weekly)
- Delivery Planning: Commitment on delivery (e.g: bi-weekly)
- Service Delivery Review: Metrics and performance (monthly)
- Operations Review: System improvement (quarterly)
📊 Metrics to Review
- Lead Time trend
- Cycle Time per column
- Throughput (tasks/week)
- Flow efficiency
- Blockers frequency
- WIP distribution
6. Improve Collaboratively
Use scientific models and experimental method for kaizen (continuous improvement).
🔬 Scientific Approach
- Hypothesis: "If we reduce WIP limit from 8 to 5, lead time will decrease"
- Experiment: Try the change for 2 weeks
- Measure: Compare lead time before/after
- Decide: Keep if it improves, otherwise rollback
Kanban Metrics: Lead Time, Cycle Time, Throughput
1. Lead Time
Definition: Total time from when task enters system to when it's completed.
Lead Time Example
📅 STORY #123: "Add forgot password feature"
Timeline:
├─ Day 1: Task added to Backlog
├─ Day 3: Task pulled to "To Do"
├─ Day 5: Development starts ("In Progress")
├─ Day 8: Code review ("Code Review")
├─ Day 9: Testing ("Testing")
└─ Day 10: Done
📊 LEAD TIME = 10 days (from entry to done)
📊 CYCLE TIME = 5 days (from "In Progress" to "Done")
Lead Time includes waiting time in backlog/queue
Cycle Time is only active work time📈 Lead Time
- Customer-facing time
- From request to delivery
- Includes waiting time
- Metric for external commitment
- Target: Continuously reduce
⏱️ Cycle Time
- Actual work time
- From start to finish
- Excludes waiting/queue
- Metric for team efficiency
- Target: Keep low and stable
2. Throughput
Definition: Number of tasks completed per time unit (e.g: tasks/week).
Throughput Chart
Tasks Completed per Week
↑
14 │ ●
12 │ ● ●
10 │ ● ● ●
8 │ ● ●
6 │
4 │
2 │
0 └───────────────────────────────→ Weeks
W1 W2 W3 W4 W5 W6 W7
Average Throughput: 10 tasks/week
Min: 8, Max: 14
📊 INSIGHTS:
- Team completes average 10 tasks/week
- Use for forecast: "80% confidence: 8-12 tasks/week"
- Relatively low variability (good!)3. Cumulative Flow Diagram (CFD)
The CFD is Kanban's most powerful chart: shows work accumulation in each column over time.
How to Read a CFD
Cumulative Tasks
↑
60 │ ┌─ DONE
│ ┌────┘
50 │ ┌────┘ ├─ TESTING
│ ┌────┘ ├─ CODE REVIEW
40 │ ┌───┘ ├─ IN PROGRESS
│ │ ├─ TO DO
30 │ │ └─ BACKLOG
│ │
20 │ │
│ │
10 │ │
│ │
0 └─┴────────────────────────────────→ Time
W1 W2 W3 W4 W5 W6
✅ HEALTHY CFD:
- Parallel bands (constant flow)
- Band width = WIP in that phase
- Slope = completion velocity
🚨 VISIBLE PROBLEMS:
- "TO DO" band widens → Accumulation! Downstream bottleneck
- "CODE REVIEW" band very wide → WIP limit too high or slow process
- Irregular bands → Unstable flowKanban vs Scrum: Detailed Comparison
| Aspect | Kanban | Scrum |
|---|---|---|
| Iterations | Continuous flow, no sprints | Time-boxed sprints (1-4 weeks) |
| Roles | No prescribed roles | PO, Scrum Master, Dev Team |
| Meetings | Optional, when needed | 5 mandatory ceremonies |
| Commitment | No scope commitment | Sprint commitment |
| Priorities | Can change continuously | Fixed during sprint |
| WIP Limits | Explicit and mandatory WIP limits | Implicit (sprint capacity) |
| Metrics | Lead Time, Cycle Time, CFD | Velocity, Burndown |
| Board | Continuous, always visible | Reset every sprint |
| Change | Evolutionary, gradual | Requires full adoption |
| Best For | Support, maintenance, ops | Product development, projects |
When to Use Kanban
✅ Kanban is Ideal for:
- Support and Maintenance: Work items arrive continuously (no batch)
- Operations/DevOps: Incident management, deployment pipeline
- Mature Agile teams: Want more flexibility than Scrum
- Variable priority work: Frequent urgencies (e.g: critical bugs)
- Multiple stakeholders: Requests from various sources
- Continuous delivery: Very frequent deploys (even daily)
⚠️ Kanban Can Be Difficult for:
- Teams new to Agile: Less structure than Scrum, requires discipline
- Projects with fixed deadlines: Sprints provide rhythm and milestones
- Distributed teams without discipline: Need ceremonies to synchronize
- Stakeholders used to commitment: Prefer "what will be ready sprint X"
Scrumban: Best of Both Worlds
Scrumban combines Scrum and Kanban, taking the best of both:
Scrumban Hybrid Approach
🔵 FROM SCRUM:
├─ Time-boxed sprints (1-2 weeks)
├─ Sprint Planning meeting
├─ Sprint Review/Demo
├─ Retrospective
└─ Optional roles (PO, SM)
🟢 FROM KANBAN:
├─ Kanban board with flow visualization
├─ Explicit WIP limits
├─ Pull system
├─ Metrics: Lead Time, CFD
└─ No fixed scope commitment
✅ WHEN TO USE SCRUMBAN:
- Scrum teams wanting more flexibility
- Kanban teams wanting regular rhythm
- Mixed support + development
- Gradual transition Scrum → KanbanImplementing Kanban: Step-by-Step Guide
🚀 Kanban Adoption Roadmap
Week 1-2: Visualize
- Map current workflow (as it really is)
- Create physical or digital board (Trello, Jira, etc.)
- Define columns that reflect real steps
- Populate board with current work items
Week 3-4: Limit WIP
- Observe how many tasks are typically in each column
- Set initial WIP limit (conservative)
- Educate team on meaning and importance
- Monitor violations and blocks
Month 2: Manage Flow
- Implement daily standup (walk the board)
- Identify and visualize blockers
- Start measuring lead time
- Create first CFD manually or with tool
Month 3+: Optimize
- Define explicit policies (DoD for each column)
- Introduce regular feedback loops
- Controlled experiments to improve (Kaizen)
- Scale or adapt system based on data
Conclusions
Kanban is a powerful and flexible method to manage workflow, particularly suited to contexts with high variability and continuous delivery. The key to success is discipline in respecting WIP limits and constant use of metrics to guide improvement.
💡 Key Takeaways
- Kanban is based on continuous flow, not time-boxed iterations
- WIP limits are the heart of Kanban: focus and bottleneck visibility
- Key metrics: Lead Time, Cycle Time, Throughput, CFD
- Evolutionary approach: start with what you do, improve incrementally
- Kanban is less prescriptive than Scrum, requires more discipline
- Ideal for support, ops, and teams with variable priorities
- Scrumban combines the best of Scrum and Kanban
📚 Next Article
In the next article we'll explore XP, Lean and DevOps: extreme technical practices (TDD, Pair Programming, CI/CD), waste elimination, and DevOps culture for continuous delivery.