A municipal call-center tooling team wants Kanban rather than Scrum. Which components correctly describe Kanban at CAPM depth?
Select an answer to reveal the explanation.
Short Explanation
Kanban’s core pitch is see the work, cap how much is open, and keep it moving. No rule says you must run Scrum sprints to do that. Flow first; timeboxes are optional add-ons, not the definition.
Full Explanation
At CAPM depth, Kanban components for a municipal call-center tooling team center on visualizing work, limiting work in progress, and managing flow—without requiring timeboxed sprints. Unlike Scrum, Kanban does not require Sprint Goals, Scrum accountabilities, or mandatory sprint boundaries. The CAPM-level distinction is flow-based control versus Scrum’s prescribed events and roles.
Mandatory Sprint Goals and a Product Owner role for every column move fails conceptually because those are Scrum constructs; Kanban does not require them for each card movement. Program Increment planning as Kanban’s only cadence mechanism fails because PI planning belongs to scaling frameworks, not to Kanban’s core flow components. A fixed predictive WBS phase gate before any card may enter "Done" fails because that imports predictive phase-gate control incompatible with continuous-flow Kanban thinking.
Exam caveat: Describe Kanban as visualize, limit WIP, manage flow—do not bolt on mandatory Scrum or SAFe events as if they were Kanban essentials. Operational check: stand up a call-center board with explicit WIP limits, measure flow, improve bottlenecks, and avoid forcing Sprint Goals onto every column transition.