Sprint Planning for an emergency-alert product produces a scattered task list—banner colors, a vendor patch, and an unused CSV export—with no Sprint Goal. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
A Sprint without a Sprint Goal is a grocery run with no dinner in mind—mustard, light bulbs, and no meal. Help the whole Scrum Team name the one alert outcome this Sprint is for. Then the task list either supports that outcome or it does not.
Full Explanation
The Sprint Goal is the commitment for the Sprint Backlog and provides coherence so Developers can negotiate scope as they learn. When Sprint Planning for an emergency-alert product produces a scattered task list—banner colors, a vendor patch, and an unused CSV export—with no Sprint Goal, the Product Owner should collaborate with the Scrum Team to form a coherent Sprint Goal that gives the Sprint Backlog a single reason to exist. Coherence toward a valuable alert outcome is the test.
Accepting the task list as the Sprint Backlog because variety proves the team is busy celebrates fragmentation. Writing a Sprint Goal privately after Planning and emailing it as a mandate skips collaboration and ownership. Asking each Developer to pick a personal goal so nobody waits on alignment replaces one Sprint Goal with fragmented individual aims.
Emergency alerts that matter to residents need one Sprint reason to exist, not a scatter of unrelated chores labeled busy.
Exam caveat: PSPO II requires a Sprint Goal as the Sprint Backlog's commitment; busy task variety without coherence is a fail.
Operational check: stop Planning long enough to name one emergency-alert outcome for the Sprint, drop or defer tasks that do not serve it, and only then finalize the forecast.