Original workplace decisions explain why learning can change a Sprint plan while goal and quality constraints remain explicit.
Find the objective before negotiating the task list
A request arriving during a Sprint is not automatically forbidden, and it is not automatically accepted. Begin with the Sprint Goal and the new information. What objective is the Scrum Team pursuing, and does the request help, threaten or leave that objective unchanged? A request can sound urgent while having little connection to the goal. Conversely, a newly discovered problem can change the best way to reach it. Naming this relationship prevents a discussion about a list of tasks from hiding the purpose of the Sprint.
The Scrum Guide allows scope to be clarified and renegotiated with the Product Owner as more is learned. During the Sprint, changes must not endanger the Sprint Goal, and quality does not decrease. Developers adapt their plan for the work. These boundaries allow flexibility without turning every interruption into an invisible replacement of the objective. The task list is a plan for achieving the goal, not a guarantee that uncertainty will disappear after Sprint Planning.
Worked case: a renewal failure
Consider a fictional membership service whose Sprint Goal is to make renewal reliable for existing members. Midway through the Sprint, support discovers that one payment route fails for a particular customer group. The failure was not in the originally selected work. Rejecting any discussion because the Sprint has started would prevent the team from using new evidence about the very outcome it is pursuing.
The Product Owner and Developers discuss what was learned, the importance of the failure and its effect on remaining work. Developers can adapt their plan and clarify or renegotiate scope with the Product Owner while protecting the goal. They might investigate a smaller response that preserves reliability rather than complete every initially imagined enhancement. The details require actual technical evidence; this fictional case does not establish a particular fix, duration or cost. The teaching point is to make the trade-off explicit instead of hiding the change.
Compare the strongest competing response
A different stakeholder now asks for a new homepage promotion unrelated to reliable renewal. That request may be valuable, but calling it urgent does not demonstrate that it fits this Sprint Goal. Inspect what taking it on would do to the objective and make the impact visible. The Product Owner’s value accountability does not make Developer capacity unlimited, and an external request does not automatically rewrite the shared plan.
Equally, a blanket rule that no scope may ever change is too rigid. It treats the initial selection as a contract against learning. Ask what changed in the evidence and which constraint the alternative respects or violates. A useful answer names the specific reason for the proposed action rather than relying on a slogan such as protect the Sprint. Protecting the goal means understanding the objective and its risks, not protecting every original task from all reconsideration.
Preserve quality and distinguish cancellation
Suppose someone proposes skipping a required integration check to fit both the renewal fix and the promotion. That is a reduction in the required quality boundary, not a scope negotiation that makes the same work Done. The Definition of Done continues to govern whether work is part of an Increment. Reorganizing or postponing work may be discussed, but missing quality evidence must remain visible.
Now consider a substantially different premise: the Sprint Goal becomes obsolete. The Guide permits the Product Owner to cancel a Sprint when its goal becomes obsolete. A new request, a difficult task or a lower forecast does not automatically establish that condition. Do not use cancellation as the default answer to every surprise. First distinguish a valuable goal needing an adapted plan from an objective that no longer makes sense. This distinction keeps the decision tied to evidence.
Use feedback without turning it into a performance claim
At Sprint Review, the Scrum Team and stakeholders inspect the outcome and relevant changes to consider what to do next. Evidence about renewal success and customer obstacles can inform that conversation. The event is a collaborative working session; it does not turn every request into an automatic next-Sprint commitment. The Product Owner remains accountable for effective backlog management and ordering.
Keep a brief decision record for your own practice: the original goal, the changed information, the option considered, the goal and quality constraints, and the reason for the choice. This is an editorial learning method, not a mandated Scrum document. Use the two checks below to change one condition at a time. Explain why your conclusion changes before viewing feedback. Repeated success on these fixed examples is practice evidence, not proof of readiness for unseen PSM I questions or a passing-score prediction.
Apply the guide
A new problem threatens the still-valuable Sprint Goal. Does Scrum require keeping every original item unchanged?Reveal explanation
No. Developers can adapt their plan and scope can be clarified or renegotiated with the Product Owner, without endangering the Sprint Goal or reducing quality.
A stakeholder labels an unrelated request urgent. Does that alone prove the Sprint Goal is obsolete and require cancellation?Reveal explanation
No. Inspect the goal and evidence. The Product Owner may cancel when the goal becomes obsolete; urgency alone does not establish that condition.
Turn the idea into practice.
Apply the rule to a new case, then explain your choice.
Practice this skillSources & authorship
Scrum Guide November 2020 supports Sprint boundaries, events and Product Owner accountability; fictional cases and the decision-record exercise are original teaching.
Original OpenExam explanation, cases and SVG informed by archive method/ambiguity research; not official Scrum.org material.
Independent educator review is pending. This guide is not an official exam paper or a video transcript.
The Scrum Guide — November 2020