A city clerk’s records desk uses Kanban-style continuous flow with WIP limits instead of Scrum sprints. What serves as a primary logical control unit in that setup?
Select an answer to reveal the explanation.
Short Explanation
Kanban is more like a checkout line with a max number of open carts than a timed soccer half. WIP limits and cards moving across columns are the control units. You do not need a Scrum sprint clock to manage that flow.
Full Explanation
When a city clerk’s records desk uses Kanban-style continuous flow with WIP limits instead of Scrum sprints, primary logical control units are work-in-progress limits and individual items flowing across the board, rather than fixed timeboxed sprints. Kanban emphasizes visualizing work, limiting WIP, and managing flow; control focuses on items and WIP constraints. Teams may still use metrics, but the method does not mandate sprint commitments or Sprint Goals as Scrum does.
Mandatory two-week sprint commitments with a Sprint Goal for every card fails conceptually because that imports Scrum’s timeboxed commitments into a flow system that does not require them. A predictive critical-path schedule that replaces the visual board entirely fails because it abandons Kanban’s visual flow control in favor of a different life-cycle mechanism. Story-point velocity charts that require a closed sprint boundary each week fail as the primary logical unit because velocity tied to closed sprints is a Scrum-style construct, not Kanban’s defining control unit.
Exam caveat: CAPM-level distinction is that flow systems use different logical units than iteration-based Scrum—WIP and items versus timeboxes and Sprint Goals. Operational check: set explicit WIP caps on the records board columns, manage blockers that stall items, and improve flow metrics without forcing every card into a Sprint Goal ceremony.