The Sprint Goal is the single objective for the Sprint and the commitment attached to the Sprint Backlog. It answers, in one sentence, why this Sprint is worth running, and because it is a single sentence, it forces the team to decide what the Sprint is actually about rather than treating it as a container for whatever was next on the list.
Commitment and flexibility, together
The Guide pairs those two words deliberately. The Developers commit to the objective, not to a fixed list of Product Backlog items, and that is what allows a team to discover mid Sprint that an item is unnecessary, drop it, and still have kept its promise. The reverse holds too, so work nobody planned can be pulled in when it turns out to be what the objective needed.
Treating the Sprint Backlog as a fixed contract removes that flexibility and leaves the team nothing to trade. Scope becomes an all or nothing question, so a Sprint in trouble either delivers everything or is reported as a failure, when the useful answer was to drop the items that were not carrying the objective.
Where it comes from
The Sprint Goal is created during Sprint Planning and added to the Sprint Backlog, so a Sprint does not begin without one. Sprint Planning covers why this Sprint is valuable, what can be Done, and how the work will get done. The Sprint Goal comes out of the first topic, and the whole Scrum Team crafts it.
The Product Owner brings the why, proposing how the product could increase its value this Sprint, and the Developers bring what is realistically achievable. An objective that survives both is one the team believes it can reach, which is what makes it a commitment rather than a target handed down. Scenario questions often offer an option in which the Product Owner or the Scrum Master announces the Sprint Goal, and the Guide places the crafting with the whole team.
Working towards it all Sprint
The Developers work toward the Sprint Goal throughout the Sprint, adapting the Sprint Backlog as they learn what the objective actually needs, which is why the Guide calls that backlog a plan by and for the Developers rather than a schedule.
The Daily Scrum is where this shows. Its purpose is to inspect progress toward the Sprint Goal and adapt the plan for the coming day, so the objective is what progress is measured against rather than the task board. If nobody has referred to the Sprint Goal since Sprint Planning, the team spent the Sprint running a list.
Why it does not change
Scope can be renegotiated with the Product Owner as more is learned, and the Sprint Goal itself is fixed for the length of the Sprint. A goal revised whenever the work turns out harder than expected is not a commitment, and a Sprint built on one becomes a report of whatever happened rather than a coherent piece of value.
The single exit is cancellation. If the Sprint Goal becomes obsolete, because the market moved or the assumption underneath it collapsed, the Sprint may be cancelled, and only the Product Owner has that authority. It stays rare, because a Sprint is short enough that finishing a poor one usually costs less than stopping it.
The commonest failure
Most weak Sprint Goals are a restatement of the selected items. "Complete items 14, 15 and 16" names the work and leaves the team nothing to negotiate scope against, because no objective exists apart from the list that could still be met if one item were dropped. It also leaves stakeholders nothing to react to at the Sprint Review beyond a count of tickets.
A goal earns its place when the work could change and the promise would still hold. "A returning customer can check out without entering their payment details again" admits several routes to it, and it answers the question that decides most Sprints, which is what to do when there is not enough time for everything.
A Sprint whose work genuinely cannot be described by one objective is a signal about the Product Backlog rather than about the wording, and the order is usually a queue of stakeholder requests rather than a path toward the Product Goal.