Kanban vs Scrum for the PMP Exam: WIP Limits, Flow Metrics & When PMI Tests Kanban

Published: 2026-05-27 · By FreePMPTests Editorial Team

Every PMP candidate studies Scrum — but a surprising number walk into the exam unprepared for Kanban questions. PMI explicitly tests Kanban concepts, and they appear in approximately 5–10% of agile-related questions. The difference is subtle but critical: while Scrum structures work around fixed-length sprints, Kanban structures work around continuous flow. Both are agile. Both appear on the exam. And the exam will test whether you know when to use each.

This article covers everything you need to know about Kanban for the PMP exam: the core practices, the flow metrics PMI expects you to interpret, the cumulative flow diagram, and — most importantly — how to distinguish a Kanban scenario from a Scrum scenario so you answer correctly.

Kanban Fundamentals: What PMI Expects You to Know

Kanban originated in Toyota's manufacturing system but was adapted for knowledge work by David J. Anderson. The framework is built on four foundational principles and six core practices. PMI doesn't test the history — it tests the application. Here's what matters:

The Four Foundational Principles

1. Start with what you do now. Kanban doesn't require a radical organizational transformation. You overlay Kanban on existing workflows. This is fundamentally different from Scrum, which mandates specific roles, events, and artifacts.
2. Agree to pursue incremental, evolutionary change. Kanban encourages small, continuous improvements — not big-bang process redesigns. This maps to PMBOK 7 Principle 11 (Embrace Adaptability and Resiliency).
3. Respect current roles, responsibilities, and job titles. Unlike Scrum, which defines three specific accountabilities, Kanban doesn't prescribe roles. Your existing team structure stays intact with Kanban overlaid on top.
4. Encourage acts of leadership at all levels. Anyone can suggest improvements. This aligns with PMI's servant-leadership philosophy — the exam rewards answers that empower the team rather than centralize decision-making.

The Six Core Practices

1. Visualize the workflow
2. Limit Work in Progress (WIP)
3. Manage flow
4. Make process policies explicit
5. Implement feedback loops
6. Improve collaboratively, evolve experimentally

For the PMP exam, practices 1–3 are the most heavily tested. Let's dive into each one.

The Kanban Board: Visualizing Workflow

The Kanban board is the central tool of the framework. It's a visual representation of work moving through defined stages. A simple board might have columns for To Do → In Progress → Done. A more detailed board might break "In Progress" into Analysis → Development → Testing → Review.

PMI tests the Kanban board through questions that describe bottlenecks. For example: "The team's Kanban board shows a large number of items piling up in the Testing column while Development is empty. What should the project manager do?" The correct answer almost always involves addressing the bottleneck — either by adjusting WIP limits, reallocating team members to testing, or investigating why testing is the constraint. This is classic Theory of Constraints thinking, which PMI values.

WIP Limits: The Heart of Kanban

Work in Progress (WIP) limits are Kanban's primary mechanism for improving flow. A WIP limit is a cap on how many work items can be in a given column at any time. For example, a "Development" column with a WIP limit of 3 means only three items can be actively developed simultaneously. When the limit is reached, the team cannot pull new work — they must finish something first.

PMI tests WIP limits because they embody core agile principles: focus, flow, and reducing multitasking. Here's what you need to know for the exam:

• WIP limits expose bottlenecks. If work piles up in front of a column, the team can see exactly where flow is breaking down. This is the diagnostic value of WIP limits.
• WIP limits reduce context switching. Research shows that multitasking destroys productivity. Limiting WIP forces team members to finish before starting new work — directly improving throughput.
• WIP limits are empirical. You don't set them once and forget. Teams experiment with WIP limits, observe the impact on flow, and adjust. This is the "evolve experimentally" practice in action.
• Scrum has an implicit WIP limit. The Sprint Backlog acts as a WIP limit — the team commits to a finite amount of work for the Sprint. Kanban makes WIP limits explicit and column-specific.

Flow Metrics: Lead Time, Cycle Time, and Throughput

PMI expects you to understand and interpret basic flow metrics. These appear in both scenario questions (diagnosing problems from metrics) and definitional questions (matching the term to its definition).

Metric	Definition	What It Tells You
Lead Time	Total time from when work is requested to when it is delivered. Clock starts when the item enters the backlog; clock stops when it's Done.	Customer experience — how long does a stakeholder wait from request to delivery?
Cycle Time	Time from when work actually starts to when it's completed. Clock starts when work enters the first "in progress" column; clock stops when it reaches Done.	Team efficiency — how long does active work take, excluding waiting time in the backlog?
Throughput	Number of work items completed per unit of time (e.g., 5 items per week).	Delivery capacity — how much work can the team complete consistently?
Work Item Age	How long a specific item has been in progress (elapsed time since work began on that item).	Aging work items — items that exceed typical cycle time signal problems.

Exam Application: Interpreting Metrics in Scenario Questions

A typical PMP Kanban question might read: "The team's average cycle time has increased from 3 days to 8 days over the last month. Throughput has dropped by 40%. The Kanban board shows a growing queue in the Code Review column. What should the project manager do?"

The correct answer identifies the bottleneck (Code Review) and proposes addressing it — for example, by temporarily reallocating team members to code review, pair-reviewing, or investigating why reviews are taking longer. Wrong answers include: "Add more items to the backlog to keep the team busy" (ignores the bottleneck), "Remove the Code Review column" (compromises quality), or "Tell the team to work faster" (anti-servant-leadership).

The Cumulative Flow Diagram (CFD)

The Cumulative Flow Diagram is the most visual tool in Kanban — and PMI has included it in exam questions. A CFD is a stacked area chart showing the number of work items in each column over time. The vertical axis is the count of items; the horizontal axis is time. Each colored band represents a workflow stage.

How to Read a CFD for the PMP Exam

• Widening bands = growing queues. If the "Testing" band gets wider over time, items are accumulating in testing. That's a bottleneck.
• Narrowing bands = work flowing out. If the "Done" band steadily grows while other bands remain stable, the system is healthy.
• Flat bands = no flow. If the "In Progress" band is flat (horizontal), no new work is being started. This could mean the team is blocked or has stopped pulling work.
• Average lead time can be approximated by drawing a horizontal line across the CFD and measuring the distance between arrival and departure.
• WIP at any point is the vertical distance between the top of one band and the bottom of the next — it's how many items are actively in that stage.

Kanban vs Scrum: When PMI Tests Each

This is the most important section for exam performance. PMI will present a scenario and ask what should be done — and whether you answer with a Scrum practice or a Kanban practice depends entirely on the clues in the scenario. Here's a side-by-side comparison to lock in the differences:

Dimension	Scrum	Kanban
Cadence	Fixed-length Sprints (1–4 weeks)	Continuous flow; no fixed iterations
Roles	Prescribed: PO, SM, Developers	No prescribed roles; existing roles maintained
Work planning	Sprint Planning commits to a Sprint Backlog	Pull system; work started when capacity is available
WIP control	Implicit (Sprint Backlog acts as WIP limit)	Explicit per-column WIP limits
Change response	Changes wait for next Sprint (unless Sprint Goal obsolete)	Changes can be pulled immediately if capacity exists
Delivery cadence	At Sprint end (or continuously within Sprint)	Continuous; deliver as soon as items are Done
Metrics	Velocity, burndown/burnup charts	Lead time, cycle time, throughput, CFD
Meetings	Prescribed events on a fixed cadence	Cadences as needed (e.g., daily standup, replenishment, delivery review)
Best for	Product development with feature-based work; teams that benefit from structured iteration	Support, operations, maintenance; work with unpredictable arrival patterns

Scenario Recognition: Scrum vs Kanban Cues

The question is probably Scrum if it mentions: Sprint, Sprint Planning, Product Owner ordering a backlog, Sprint Review with stakeholders, Sprint Retrospective, Daily Scrum, burndown chart, velocity, Sprint Goal, timeboxed iteration, Definition of Done tied to a Sprint boundary.

The question is probably Kanban if it mentions: WIP limits on columns, lead time or cycle time metrics, a cumulative flow diagram, "pull system," work items flowing continuously, no mention of Sprint boundaries or Scrum roles, context is support/maintenance/operations, the existing process is being overlaid rather than replaced.

The question is hybrid (Scrumban) if it mentions: A Kanban board used within Sprints, WIP limits on a Scrum board, continuous delivery with Sprint planning, teams combining Scrum events with Kanban flow metrics. Scrumban is a real-world hybrid that PMI acknowledges but doesn't test deeply — recognize it exists but answer based on the specific practice the question describes.

Common PMP Kanban Scenarios (with Correct Answers)

Scenario 1: Bottleneck Detection

"The team's CFD shows the 'Testing' band growing wider each week while 'Development' is shrinking. What should the Scrum Master do?"

Correct: Facilitate a discussion with the team to identify why testing is the bottleneck and experiment with solutions — such as adjusting WIP limits or temporarily shifting team members. Wrong: Add more developers (doesn't unblock testing), remove WIP limits (masks the problem), escalate to management (the team should solve its own process issues).

Scenario 2: WIP Limit Violation

"A team member pulls a sixth item into the 'Development' column despite a WIP limit of 5. What should the project manager do?"

Correct: Remind the team member of the WIP limit and the reason it exists (to maintain flow and reduce context switching), and coach on why finishing before starting is important. Wrong: "Increase the WIP limit to 6" (adjusting WIP limits should be a deliberate team decision based on data, not a reaction to violation), "Reprimand the team member" (anti-servant-leadership).

Scenario 3: When to Use Kanban Over Scrum

"The IT operations team handles incident tickets, infrastructure changes, and small enhancement requests. Work arrives unpredictably. The team finds it difficult to plan two-week Sprints because priorities shift daily. What should be recommended?"

Correct: Transition to Kanban — visualize the workflow on a Kanban board, set WIP limits, and use flow metrics to manage delivery. Kanban is ideal for work with high variability and frequent priority changes. Wrong: "Shorten Sprints to one week" (still forces timebox planning on inherently unpredictable work), "Reject any work that arrives mid-Sprint" (support teams can't do this), "Move to pure predictive waterfall" (regressive).

Study Strategy: Kanban in 30 Minutes

You don't need a deep Kanban certification to pass PMP questions on this topic. Focus on these high-yield areas:

1. Memorize the flow metrics definitions. Lead time (request to delivery) vs. cycle time (start to finish). This is a straightforward definition question that PMI asks regularly.
2. Learn to read a CFD. Widening band = bottleneck. Flat band = no flow. Growing "Done" band = healthy system. Practice with two or three sample diagrams.
3. Understand WIP limit purpose. It's about flow optimization, not performance management. Know that WIP limits reduce multitasking and expose bottlenecks.
4. Master the Scrum-vs-Kanban recognition cues. Sprint words → Scrum. Flow words → Kanban. This alone will get you through 80% of the approach-identification questions.
5. Know when Kanban is preferred. Operations, support, maintenance, unpredictable work arrival — these contexts favor Kanban. Product development with feature-driven roadmaps favors Scrum.

Kanban doesn't require the same depth of study as Scrum for the PMP exam, but ignoring it entirely is a mistake. A solid hour of focused Kanban review — paired with practice questions that test the distinctions covered in this article — will give you the confidence to handle every Kanban question the exam throws at you.