A school-enrollment product team is told to finish a separate 'release planning' phase and lock next year's dates before any Sprint starts. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
A separate release-planning banquet before school enrollment 'starts' is leftover waterfall — the cafeteria is already serving. Forecasts get updated while real Sprints run, not locked in a phase that pretends uncertainty is gone. Keep the outlook inside the same Scrum events that inspect actual Increments.
Full Explanation
Forecasting for a school-enrollment product belongs inside ongoing Scrum events—Sprint Planning, Sprint Review, and Product Backlog refinement—not in a separate pre-Sprint release planning phase that locks next year's dates. Declining that planning phase keeps empiricism alive once Sprints start. Approving the phase and freezing the release calendar so Sprints only execute already-decided dates recreates waterfall inside Scrum language. Handing the calendar to the Scrum Master for one release-planning workshop and then treating Sprints as a construction phase similarly separates planning from learning. Moving all forecasting into a separate PMO release train while limiting Scrum events to daily status removes Product Owner accountability for the outlook. Exam caveat: Scrum has no mandatory up-front release-planning phase that freezes dates before empiricism begins. Operational check: cancel the separate lock-down phase, refine enrollment backlog continuously, and update the year outlook at each Sprint Review from Done Increments rather than from a pre-Sprint calendar workshop. School-enrollment forecasting inside Scrum events keeps learning coupled to delivery; a pre-Sprint lock-down calendar recreates waterfall and makes later adaptation look like failure. Update the year outlook from Done Increments at each Review rather than from a one-time workshop.