Kanban in the Google PM Certificate: What You Learn and When to Use It
Course 5 of the Google PM Certificate introduces two major Agile frameworks: Scrum and Kanban. While Scrum (with its sprints and ceremonies) gets more attention, Kanban is equally valuable for certain types of work. Understanding when to use Kanban over Scrum is important for your PM toolkit. This article explains Kanban, its core principles, and how it differs from Scrum in real-world application.
What is Kanban?
Kanban is a lean method for managing work flow. "Kanban" literally means "visual card" in Japanese (from manufacturing). The core idea: make work visible, limit what's in progress, pull work based on capacity. Unlike Scrum's sprints (time-boxed iterations), Kanban is continuous. Work flows through the system based on team capacity.
Core principle: Flow matters more than sprints. Minimize time work sits in progress. Deliver continuously, not in batches.
The Kanban Board: Making Work Visible
A Kanban board has columns representing workflow stages. Simple example:
- To Do (backlog)
- In Progress (someone is working on it)
- In Review (waiting for approval/review)
- Done (completed)
More complex boards might have: To Do → In Progress → Testing → Ready for Release → Released.
The key: cards (representing work items) move left-to-right across the board as they progress. Everyone sees the board. Transparency and visibility.
Work-In-Progress (WIP) Limits: Each column has a limit on how many cards can be there at once. Example:
- To Do: Unlimited (backlog)
- In Progress: 3 (only 3 people can be actively working at once)
- In Review: 2 (only 2 items can be in review queue)
- Done: Unlimited
WIP limits force focus. If "In Progress" is full, people pull from the queue and push items forward before starting new work. This prevents multitasking and bottleneck accumulation.
How Kanban Differs from Scrum
| Aspect | Kanban | Scrum |
|---|---|---|
| Time-boxing | Continuous flow | Sprints (2-4 weeks) |
| Iteration | None (continuous) | Fixed sprint cycles |
| Planning | Ongoing; pull-based | Sprint planning ceremony |
| Changes | Can enter backlog anytime | Only between sprints (usually) |
| Roles | Minimal (just facilitator) | PO, SM, Team |
| Metrics | Cycle time, lead time, flow | Velocity, burndown |
| Best for | Ongoing ops, support, bugs | Product development, features |
Scrum has formal ceremonies and sprints. Kanban has no ceremonies—just the board and continuous flow.
Core Kanban Metrics
Lead Time: How long from when a request enters the system until it's delivered. Includes waiting time. "User reports a bug Monday; it's fixed Friday = 5 days lead time."
Cycle Time: How long actively working on an item (excluding waiting). "User reports bug Monday; we start Tuesday, finish Wednesday = 2 days cycle time." Cycle time is subset of lead time (work time + wait time = lead time).
Throughput: How many items the team completes per time period. "We close 15 bugs per week."
Kanban focuses on minimizing lead time and variability. Lower, more predictable lead times = better customer experience.
When to Use Kanban
Use Kanban for ongoing, continuous work:**
- Customer support (tickets come in continuously, no "sprint")
- Operations (monitoring, incident response, maintenance)
- Bug fixes (emergencies come anytime, need to be handled)
- DevOps / Infrastructure (monitoring, deployment, patches)
- Content teams (publishing happens continuously)
- Finance / Accounting (transactions ongoing)
Don't use Kanban if:**
- Work comes in large batches that need planning (use Scrum)
- You need predictable delivery dates for specific features (Scrum better)
- Team works in shifts/unreliable availability (Scrum's planning helps)
- You have dependencies across multiple teams (Scrum's planning coordinate)
Kanban in Practice: A Support Team Example
Imagine a customer support team. Tickets come in all day. Some are urgent, some can wait. Traditional project management (Waterfall) doesn't work; you can't plan "Q2 support project." Scrum struggles (sprint what? Support is continuous).
Kanban shines:
- Backlog: All incoming tickets (prioritized by severity/urgency)
- In Progress: 5-person team, so max 5 tickets being worked simultaneously (WIP limit)
- Resolved: Ticket solved, sent to customer
- Closed: Customer confirms it's fixed
Tickets flow based on team capacity. As soon as someone closes a ticket, they pull the next-highest priority from the backlog. Lead time varies but is measurable. "We resolve 95% of support tickets within 24 hours."
Hybrid: Scrumban
Many teams blend Scrum and Kanban ("Scrumban"):
- Use Scrum sprints for feature development
- Use Kanban for bug fixes and support (continuous flow)
- Sprint planning focuses on features; bugs are pulled continuously based on WIP limits
This handles both planned and unplanned work realistically.
Kanban Misconceptions
Misconception 1: "Kanban means no planning."**
Wrong. Kanban still requires backlog prioritization. You're just not planning sprints. You prioritize the backlog, and the team pulls based on capacity.
Misconception 2: "Kanban works for any type of work."**
No. Kanban is optimized for continuous, ongoing work with variable arrival times. If you're building a product with planned releases, Scrum is usually better.
Misconception 3: "Kanban requires no estimation."**
You can estimate or not. But estimates help predict capacity. "If this feature is 13 points and our team velocity is 35 points per week, it'll take ~3 days."
Misconception 4: "Kanban has no ceremonies."**
Kanban is lighter on ceremonies, but most teams still have: standup (daily or frequent), backlog refinement, and retrospectives. Just not sprint planning and reviews.
Interview Questions on Kanban
Q: "What's Kanban and when would you use it?"**
A: "Kanban is a continuous-flow method for managing work. Instead of sprints, work flows based on team capacity. I'd use Kanban for ongoing, variable work—customer support, bug fixes, DevOps—where you can't predict release dates upfront. I'd use Scrum for feature development with planned releases. Kanban's strength is predictability and responsiveness; Scrum's strength is managing scope toward release dates."
Q: "What's the difference between Kanban and Scrum?"**
A: "Scrum uses time-boxed sprints and planned iterations. Kanban is continuous flow. Scrum suits feature development; Kanban suits ongoing operations. Kanban focuses on lead time and cycle time; Scrum focuses on velocity and sprint predictability."
Related reading: Compare Kanban to Waterfall and explore the Scrum framework in detail.
Next Steps
If you want a structured study companion, our Google PM Certificate Study Guide covers the full 6-course breakdown, a week-by-week study plan, and 50 practice questions with answer explanations—everything you need in one place.
For AI-powered tutoring, SimpuTech's Google PM Certificate study coach walks you through practice questions, explains concepts you're stuck on, and builds a custom study plan around your schedule. Try it free for 1 day.
Program details verified against grow.google/certificates/project-management as of March 2026. Pricing and course structure are subject to change—confirm current details before enrolling.