A sprint goal describes the business purpose and value of the sprint. The sprint goal is the foundation of a mutual commitment made by the development team and the product owner. The team commits to meeting the goal by the end of the sprint; the product owner commits to not altering the sprint goal during the sprint.
It's this last part—no changes to the sprint goal during the sprint—that sometimes causes confusion, especially in teams new to Scrum and agile.
Clarifications DURING SPRINT? Yes. Changes? No.
The first nebulous area has to do with distinguishing between a true change and a clarification. Although the sprint goal should not be materially changed during a sprint, it can be clarified. Sprint goal changes are alterations in work or resources that have the potential to generate waste, disrupt the flow of work, or increase the scope of work. A common example might be adding a product backlog item, or significantly expanding the scope of a product backlog item.
Sprint goal clarifications, on the other hand, are additional details provided to help the team achieve its sprint goal. It is completely reasonable for the team to ask clarifying questions about product backlog items during the sprint, and for the product owner to answer. An example of a clarifying question might be whether results should be sorted alphabetically or by type.
What About Embracing Change?
It might seem that the “no-sprint-goal-altering-changes rule” is in direct conflict with the core Scrum principle that we should embrace change. Remember that Scrum teams do embrace change, but in a balanced, economically sensible way. In other words, they must consider the economic consequences, the waste, associated with the change, which increases in relation to the level of investment in the changed work. For more on this, read the blog post “Economically Sensible Change.” The economics can also be affected by the potential deterioration of team motivation and trust that can accompany a change.
Not Changing the Sprint Goal Is a Rule, Not a Law
With that being said, remember that the no-sprint-goal-altering-changes rule is a rule, not a law. If the economic consequences of making the change are far less than the economics consequences of deferring the change, making the change is the smart business decision. Making pragmatic decisions with Scrum is why it is so imperative to understand the agile principles behind the Scrum framework.
What If the Sprint Goal Becomes invalid?
If the sprint goal becomes completely invalid, the Scrum team may decide that continuing with the current sprint makes no sense and advise the product owner to abnormally terminate the sprint. If the product owner agrees, the sprint comes to an abrupt end and, as a default behavior, the Scrum team meets to perform a sprint retrospective (other actions might be more sensible given the reason for terminating the sprint). The Scrum team then meets with the product owner to plan the next sprint. Keep in mind that this is a serious disruption of the fast, flexible flow of features; as such, it should be a rare event that is used only when an economically significant event occurs that completely invalidates a sprint.
In summary, unless there is a compelling economic reason to change a sprint goal, don't do it!