Principles of Product Management: Kanban (Work in Progress Limits, Flow Metrics, Cumulative Flow Diagram)

Kanban (Work in Progress Limits, Flow Metrics, Cumulative Flow Diagram)

Kanban for Product Managers: A Practical Study Guide

What This Is

Kanban is a visual workflow management method that helps product teams limit work in progress (WIP), optimise flow, and deliver value faster by making bottlenecks visible. Unlike Scrum (time-boxed sprints), Kanban is continuous and adaptive, making it ideal for teams handling unpredictable workloads (e.g., bug fixes, customer support requests, or feature iterations). Why it matters: Poor flow leads to delays, context-switching, and wasted effort—Kanban fixes this by enforcing discipline without rigid processes.

Real-world example: A fintech startup used Kanban to reduce their feature lead time from 21 to 7 days by limiting WIP and visualising blockers in their Cumulative Flow Diagram (CFD). This allowed them to ship a critical fraud-detection update ahead of a competitor’s launch.

Key Terms & Frameworks

• Kanban Board: A visual tool (columns = workflow stages, cards = tasks) to track work. Example columns: Backlog → Ready → In Progress → Review → Done.
• Work in Progress (WIP) Limits: Maximum number of tasks allowed in a column at once. Formula: WIP Limit = Team Capacity × 0.7 (e.g., 4 engineers → WIP = 3). Prevents multitasking and exposes bottlenecks.
• Flow Metrics: Key performance indicators (KPIs) to measure efficiency:
• Cycle Time: Time from start to completion of a task. Formula: End Date – Start Date.
• Lead Time: Time from request to delivery (includes queue time). Formula: Delivery Date – Request Date.
• Throughput: Number of tasks completed per unit time (e.g., 5 features/week).
• Cumulative Flow Diagram (CFD): A stacked area chart showing work items in each stage over time. How to read it:
• X-axis: Time.
• Y-axis: Number of tasks.
• Bands: Workflow stages (e.g., Backlog, In Progress, Done).
• Bottleneck signal: A band widening (e.g., In Progress grows while Done stays flat).
• Little’s Law: Predicts cycle time based on WIP and throughput. Formula: Cycle Time = WIP / Throughput. Example: 10 tasks in progress, 2 tasks completed/day → Cycle Time = 5 days.
• Pull System: New work is only started when capacity is available (vs. "push" systems where work is assigned regardless of bandwidth).
• Explicit Policies: Team-agreed rules (e.g., "No more than 2 tasks in Review at once"). Reduces ambiguity.
• Classes of Service: Prioritisation categories (e.g., Expedite, Standard, Fixed Date). Example: A P0 bug gets "Expedite" status and bypasses WIP limits.
• Blockers: Tasks stuck due to dependencies (e.g., waiting on design). Visualised with a red dot on the Kanban card.
• Flow Efficiency: % of time a task is actively worked on vs. waiting. Formula: Active Time / Total Lead Time × 100. Aim for >40% (most teams are <20%).
• Kanban Cadences: Regular meetings to improve flow:
• Daily Standup: Focus on blockers, not status updates.
• Flow Review: Analyze CFD and metrics weekly.
• Retrospective: Adjust WIP limits and policies monthly.

Step-by-Step: Implementing Kanban in a Product Team

1. Map Your Workflow
2. Draw columns for each stage of your process (e.g., Backlog → Spec → Dev → QA → Release). Include "Done" criteria for each column (e.g., QA Done = "Tested on staging + 0 critical bugs").

3. Pro tip: Start with your current process (even if messy)—don’t over-optimise upfront.

4. Set WIP Limits

5. Calculate initial limits: Team size × 0.7 (e.g., 5 engineers → WIP = 3–4). Adjust based on bottlenecks (e.g., if Review is always full, lower its WIP).

6. Example: A mobile app team sets WIP = 2 for In Progress to force pairing and reduce context-switching.

7. Visualise Work and Blockers

8. Use a tool (e.g., Jira, Trello, Miro) to create cards for tasks. Add:
   • Blockers: Red dot + dependency owner (e.g., "Waiting on Legal").
   • Classes of Service: Color-code (e.g., red = Expedite, blue = Standard).

9. Pro tip: Include lead time and cycle time on cards for transparency.

10. Measure and Optimise Flow

11. Track flow metrics (cycle time, throughput) weekly. Use a CFD to spot trends (e.g., QA band widening = testing bottleneck).

12. Example: A CFD shows In Progress growing while Done is flat → Team lowers In Progress WIP from 4 to 2 and pairs engineers to unblock tasks.

13. Hold Flow Reviews

14. Weekly 30-minute meeting to:
    • Review CFD and metrics (e.g., "Cycle time increased from 3 to 5 days—why?").
    • Adjust WIP limits (e.g., "Lower Review WIP from 3 to 2").
    • Remove blockers (e.g., "Assign a dedicated QA resource").

15. Pro tip: Focus on systems, not people (e.g., "Why is Review a bottleneck?" vs. "Why is Alice slow?").

16. Continuously Improve

17. Monthly retrospective to:
    • Refine policies (e.g., "New rule: No more than 1 Expedite task at a time").
    • Experiment with changes (e.g., "Let’s try WIP = 1 for Dev for 2 weeks").
18. Example: A team reduces lead time by 30% after adding a Ready for Dev column to filter well-defined tasks.

Common Mistakes

• Mistake: Setting WIP limits too high (e.g., WIP = 10 for a 5-person team).
  Correction: Start with WIP = Team Size × 0.7 (e.g., 5 people → WIP = 3–4). High WIP hides bottlenecks and encourages multitasking.

• Mistake: Ignoring blockers (e.g., tasks sit in Review for days with no action).
  Correction: Visualise blockers (e.g., red dot + owner) and escalate daily. Blockers are the #1 cause of delays.

• Mistake: Treating Kanban as a "to-do list" (e.g., no WIP limits, no flow metrics).
  Correction: Kanban is about flow, not just visualisation. Enforce WIP limits and track metrics to drive improvements.

• Mistake: Not defining "Done" criteria (e.g., QA Done = "Tested" vs. "Tested + 0 critical bugs").
  Correction: Write explicit policies for each column. Ambiguity leads to rework.

• Mistake: Over-optimising early (e.g., adding 10 columns for a 3-person team).
  Correction: Start simple (3–5 columns) and refine as you learn. Complexity slows you down.

PM Interview / Practical Insights

1. Interviewer Probe: "How would you use Kanban to reduce feature lead time?"
2. Answer: Start by mapping the workflow, setting WIP limits, and tracking a CFD to identify bottlenecks. Example: If QA is the bottleneck, lower its WIP and add automation.

3. Trap: Don’t say "Just add more QA engineers"—focus on systems (e.g., WIP limits, automation).

4. Stakeholder Question: "Why not just use Scrum instead of Kanban?"

5. Answer: Kanban is better for unpredictable work (e.g., bug fixes, customer requests) because it’s continuous (no sprints). Scrum works well for planned, iterative work (e.g., feature development).

6. Trap: Avoid saying "Kanban is easier"—highlight its strengths (flexibility, flow optimisation).

7. Tricky Distinction: "What’s the difference between cycle time and lead time?"

8. Cycle Time: Time from start to finish (e.g., "Coding started on Monday, finished on Friday → 5 days").
9. Lead Time: Time from request to delivery (e.g., "Feature requested on Jan 1, delivered on Jan 15 → 15 days").

10. Why it matters: Lead time includes queue time (e.g., waiting for prioritisation), which is often the biggest delay.

11. Interviewer Probe: "How do you handle a stakeholder who wants to add an ‘urgent’ task mid-sprint?"

12. Answer: Use Classes of Service:
    1. Assess if it’s truly Expedite (e.g., P0 bug) or Standard (e.g., minor UI tweak).
    2. If Expedite, bypass WIP limits but stop another task to avoid overloading the team.
    3. Update the CFD to show the impact (e.g., "Adding this task will delay 2 others").
13. Trap: Don’t say "Just add it"—explain the trade-offs.

Quick Check Questions

1. Scenario: Your team’s CFD shows the In Progress band widening while Done stays flat. What’s the likely bottleneck, and how do you fix it?
2. Answer: The bottleneck is likely downstream (e.g., Review or QA). Fix by lowering WIP limits in In Progress and pairing engineers to unblock tasks.

3. Why: A widening In Progress band means work is piling up before the next stage.

4. Scenario: A stakeholder asks, "Why can’t we start 10 features at once? We’ll finish them faster!" How do you respond?

5. Answer: Explain that multitasking increases cycle time (Little’s Law: Cycle Time = WIP / Throughput). Example: Starting 10 features at once might take 20 weeks, but starting 2 at a time could take 5 weeks each (total 10 weeks).

6. Why: Context-switching and bottlenecks slow everything down.

7. Scenario: Your team’s flow efficiency is 15%. What does this mean, and how do you improve it?

8. Answer: Flow efficiency = % of time tasks are actively worked on (vs. waiting). 15% means tasks spend 85% of their time blocked or queued. Improve by:
   • Reducing WIP limits.
   • Automating handoffs (e.g., CI/CD).
   • Removing dependencies (e.g., cross-training engineers to do QA).
9. Why: Low flow efficiency = wasted time and slower delivery.

Last-Minute Cram Sheet

1. Kanban = Visual + WIP Limits + Flow Metrics (not just a to-do list).
2. WIP Limit Formula: Team Size × 0.7 (e.g., 5 people → WIP = 3–4).
3. Cycle Time vs. Lead Time: Cycle = start to finish; Lead = request to delivery.
4. Little’s Law: Cycle Time = WIP / Throughput (e.g., 10 tasks, 2/day → 5 days).
5. CFD Bottleneck Signal: A band widening (e.g., In Progress grows while Done stays flat).
6. Flow Efficiency Formula: Active Time / Total Lead Time × 100 (aim for >40%).
7. Classes of Service: Expedite, Standard, Fixed Date (prioritise with WIP exceptions).
8. Blockers: Visualise with red dots + owner (escalate daily).
9. ⚠️ Don’t set WIP limits too high—it hides bottlenecks.
10. ⚠️ Kanban ≠ Scrum: Kanban is continuous (no sprints), Scrum is iterative (time-boxed).