Several city departments want a shared permitting platform and schedule a large, multi-team planning event to align features for the next program increment. Which framework-level component are they adopting that basic single-team Scrum does not include?
Select an answer to reveal the explanation.
Short Explanation
Picture a citywide traffic light sync—lots of crews, one big planning jam. That’s the flavor of SAFe® PI Planning. Plain single-team Scrum never invented that multi-team program event; it stays at one team’s Sprint cadence.
Full Explanation
Several city departments scheduling a large, multi-team planning event to align features for the next program increment on a shared permitting platform are adopting SAFe® PI Planning—a scaling event that coordinates multiple teams and is not part of basic single-team Scrum. CAPM-level recognition is that PI Planning sits at framework and scaling level beyond single-team Scrum’s events, roles, and artifacts. Municipal shared platforms often need that cross-team alignment when departments must synchronize a coherent permitting increment.
A Daily Scrum limited to fifteen minutes for one Development Team fails conceptually because that is a single-team Scrum coordination event, not multi-team PI Planning. A Sprint Review for a single Scrum Team’s Increment fails for the same reason: it is team-level inspection of one increment, not a program-increment alignment event across departments. A Definition of Done checklist owned solely by one Scrum Master fails because DoD is a quality agreement for completion criteria, not a multi-team PI Planning ceremony.
Exam caveat: Distinguish scaling PI Planning from single-team Daily Scrum, Sprint Review, and DoD artifacts; CAPM asks for recognition, not full SAFe practitioner technique. Operational check: if permitting platform teams need cross-team alignment, treat PI Planning as an explicit scaling choice with preparation inputs and committed outcomes; do not claim basic Scrum already included that event.