The Sprint Goal is the single objective for the Sprint and the commitment attached to the Sprint Backlog. One sentence has to say why the Sprint is worth running, and the discipline of one sentence is the point. A team that cannot write that sentence has not yet decided what the Sprint is about, and it is filling the Sprint with whatever sat next on the list.
Commitment and flexibility together
That one sentence is also a commitment, and the Guide pairs commitment with flexibility deliberately. The Developers commit to the objective and never to a fixed list of Product Backlog items, which is what allows a team to discover mid Sprint that an item is unnecessary, drop it and keep its promise all the same. The same flexibility works in the other direction, so work nobody planned at Sprint Planning can enter the Sprint Backlog once 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 never carrying the objective.
How the Scrum Team crafts the Sprint Goal
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 three topics, which are why this Sprint is valuable, what the Developers can complete to the Definition of Done and how they will do the work. The Sprint Goal comes out of the first topic, and the whole Scrum Team crafts it.
The Product Owner proposes how the product could increase its value this Sprint, and the Developers bring what they can realistically achieve. An objective that survives both inputs 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 the Sprint Goal all Sprint
The Developers work toward the Sprint Goal throughout the Sprint, adapting the Sprint Backlog as they learn what the objective actually needs. That is why the Guide calls the Sprint Backlog a plan by and for the Developers. A plan the Developers own can change on any day of the Sprint, and a schedule handed to them could not.
The Daily Scrum is the event that makes this visible. Its purpose is to inspect progress toward the Sprint Goal and adapt the plan for the coming day, so progress gets measured against the objective and the state of the task board is secondary. If nobody has mentioned the Sprint Goal since Sprint Planning, the team has spent the Sprint running a list.
What the Scrum Master does about the Sprint Goal
A team running a list is exactly the condition a Scrum Master is accountable for noticing, since the accountability is for the Scrum Team's effectiveness and a Sprint with an unused goal has given up the thing that held it together. What follows is coaching. A Scrum Master asks at Sprint Planning whether the proposed goal could survive dropping an item, keeps the goal in view at the Daily Scrum by asking about progress towards it and names the drift when four Developers are each carrying unrelated work.
None of that makes the Sprint Goal the Scrum Master's to write. The whole Scrum Team crafts it, so a Scrum Master who supplies the wording has removed the negotiation the event exists for, and a Scrum Master who overrules a weak goal has taken a decision that belonged to the team. The service is coaching a team towards a goal worth defending, and then holding the team to the goal it chose for the length of the Sprint.
Why the Sprint Goal does not change
Scope can be renegotiated with the Product Owner as more is learned, and the Sprint Goal itself stays 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 ends as a report of whatever happened, with no coherent piece of value in it.
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. Cancellation stays rare, because a Sprint is short enough that finishing a poor one usually costs less than stopping it.
The commonest failure in a Sprint Goal
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.
If a Sprint's work genuinely cannot be described by one objective, the Product Backlog is where to look, because the order is usually a queue of stakeholder requests with no path toward the Product Goal running through it.