Kanban and Flow Metrics on the PMP Exam: WIP Limits, Cycle Time, and CFDs

A telecom operations team abandons its third sprint in a row. Half of every "committed" sprint gets displaced by urgent defects that can't wait two weeks, and the retrospective has turned into an apology ritual. A new project manager proposes stricter sprint discipline. On the PMP exam, that project manager just picked a distractor. The team doesn't have a discipline problem — it has a workflow that doesn't fit timeboxes. That diagnosis, and the flow vocabulary behind it, is what Kanban questions actually test.

The vocabulary the exam assumes you own

• WIP limit — a cap on how many items may occupy a workflow state at once. It converts the board into a pull system: you start new work only when capacity frees up. The principle behind it: stop starting, start finishing.
• Cycle time — how long an item takes from the moment work starts until it's done. The team's clock.
• Lead time — how long from the moment the request was made until it's delivered. The customer's clock. Lead time includes waiting; that's why it's almost always longer.
• Throughput — completed items per unit of time.

These connect through Little's law: on average, cycle time equals WIP divided by throughput. You won't need to derive it, but you must own its consequence — with throughput steady, more work in progress means longer cycle times, not more output. So the exam's counterintuitive right answer is often: to deliver faster, start less.

Reading a cumulative flow diagram

A CFD stacks colored bands, one per workflow state, over time. Three reads cover nearly every exam question:

1. Slope of the "done" band — throughput. Flattening slope means delivery is stalling.
2. Width of any band — WIP sitting in that state. A band that keeps widening is a bottleneck: work enters that state faster than it leaves.
3. Horizontal distance across the bands — approximate lead time for an item entering then.

Parallel, steady bands mean healthy flow. When a stem shows a swelling band, the tested response is to fix the constraint — limit WIP there, swarm the queue — not to push more work into the system or add people upstream of the problem.

When Kanban beats Scrum (the exam's signals)

Choose flow-based Kanban when the stem describes: work arriving continuously and unpredictably; interrupt-driven operations, support, or maintenance; items that are independent and vary in urgency; priorities that shift faster than a sprint cadence. Scrum earns its keep when a stable team pursues a cohesive product goal and benefits from batch feedback each iteration. Kanban is also the evolutionary option — "start where you are" — which makes it the right recommendation for teams that can't absorb a role-and-events restructuring. Hybrids like Scrum with WIP limits exist too; the exam rewards matching method to work, not loyalty to a framework. For the broader selection logic, see agile vs. predictive on the 2026 exam.

Two exam-style scenarios

Scenario 1. A healthcare claims team's cumulative flow diagram shows the "In review" band tripling in width over three weeks while the "Done" band's slope flattens. What should the project manager do first?

• A. Add two analysts to the intake stage to keep the pipeline full
• B. Set a WIP limit on the review state and have the team swarm the existing review queue
• C. Extend working hours until the accumulated reviews clear
• D. Remove the review step to simplify the workflow

Answer: B. A widening band plus falling throughput is a textbook bottleneck at review. Limiting WIP stops feeding the constraint and swarming drains it. A makes the problem worse — more arrivals into a clogged system. C burns people to compensate for a system problem and doesn't scale. D deletes a control instead of fixing capacity; the review presumably exists for a reason.

Scenario 2. A financial services team handles regulatory change requests that arrive unpredictably, vary widely in size, and each carry a regulator deadline. The team currently locks scope into two-week sprints and keeps missing deadlines as urgent items wait for the next sprint. What should the project manager recommend?

• A. Move to one-week sprints so urgent items wait less
• B. Adopt a flow-based approach with WIP limits and manage performance by cycle time
• C. Reserve buffer capacity in each sprint for urgent arrivals
• D. Return to a predictive plan with formal change control for each request

Answer: B. Continuous, deadline-driven arrival is the signature Kanban use case: pull each item when capacity frees, track cycle time against the regulator's clock. A halves the wait but keeps the mismatch. C is a workaround that admits the batch model doesn't fit. D adds process latency to work that needs less waiting, not more.

The heuristics worth memorizing

When a stem names cycle time, throughput, WIP, or shows a CFD, answer from flow: fix the system before adding people, limit WIP before extending hours, measure the current state before reorganizing. Flow metrics are a spot where strong candidates quietly bleed points — see where they sit in our hardest PMP topics analysis. And if velocity is your team's forecasting tool instead, our agile estimation guide covers the equivalent traps.

The only way this becomes instinct is repetition with feedback. ExamElephant gives you 75 free exam-style questions, and every one you miss comes back at 3 and 7 days until you've mastered it — which is exactly how bottleneck-reading stops being a puzzle and starts being a glance.

FAQ