✥ ✥ ✥
Because the work plan is described in terms of individually-sized work items, it’s easy for team members to pick up an individual item and work on it in isolation. However, that dilutes the innovation that comes from the interactions between individuals who bring different perspectives to the work. It also makes it easy for cubicle walls to become barriers to continuously communicating insights that have importance beyond the individual developer, and teamwork suffers.
To ensure that value is delivered to the stakeholders at the end of the Sprint it might be needed to re-plan a running Sprint. A reason for this can be that new work emerges, due to the teams latest insights. If the team would follow the original work plan they won’t create the greatest value possible. Another common occurrence is that partway through the Sprint, it becomes clear that the team will not complete every SBI in the Sprint Backlog. This is often due to the work required to complete SBIs. You still want to deliver something of value, if at all possible. Re-planning the work for the Sprint requires forethought and time.
Another scenario is that important technical knowledge about certain Product Backlog Items (PBIs) becomes critical to specify them completely and clearly enough. A technical prototype may be needed to validate a proposed architecture or to learn performance characteristics of some technology. While such work should be identified in a PBI, its uncertain nature requires that the team focus should be on the knowledge to be obtained rather than completing all the work planned.
In some cases, the greatest value might not be an explicit Product Backlog Item. To give one example, the greatest value for the team was to increase revenue per Sprint, and the team devoted a Estimation Points to this effort. On the other hand, sometimes the bulk of the Sprint’s value derives largely from one critical PBI out of many.
The entire Scrum Team jointly creates the Sprint Goal. The Product Owner will naturally guide the creation of the Sprint Goal because he or she has the best view on the next step towards the Product Vision and on how to create the Greatest Value. The Scrum Team should commit to the Sprint Goal as something always within reach.
✥ ✥ ✥
The Sprint Goal can be used to frame the selection of PBIs for the Sprint but in some sense the Sprint Goal is more important even than the sum of the individual PBIs. The Sprint Goal creates coherency in the PBIs helping to create a valuable Product Increment. One good initial approach to a Product Backlog is to express it as a list of Sprint Goals, which the Product Owner and Development Team together elaborate into PBIs.
Autonomous Teams states that team members must be able to manage themselves to accomplish their goals, and Developer-Ordered Work Plan states that Development Teams must be free to order their work however they see fit. The Sprint Goal is the sole mechanism by which the Product Owner can influence the potential order in which the Development Team carries out its work (by inferring urgency from the importance conveyed by the Sprint Goal) — but, again, only with the Developers’ consent.
During the Sprint Planning the Scrum Team determines what is to be achieved at the end of the Sprint. This is formulated in the initial Sprint Goal. The Development Team defines the details on how to accomplish this Sprint Goal by creating a Sprint Backlog. If the Development Team concludes that they cannot accomplish the Sprint Goal they should refine the Sprint Goal with the Product Owner. A key output of Sprint Planning is that the Development Team should be able to explain how it can accomplish the Sprint Goal and how they know they have accomplished it. The ability to explain it comes through a thorough understanding of the work to be done, which raises the probability that the team actually can accomplish it within the Sprint. The Scrum Team commits to the Sprint Goal. This Sprint Goal also gives the Development Team a Unity of Purpose and it serves as a connection to stakeholders that builds trust in the team.
The Sprint Goal should be visible to the team; for example, put it on the Scrum Board or other Information Radiator.
The Sprint Backlog is kept current during the Sprint to support meeting the Sprint Goal. Progress on the Sprint Backlog (such as indicated on a Sprint Burndown Chart) is like progress down the soccer field during a Sprint: though each yard of progress brings the ball closer to the end, the value comes in the goal. But it is sometimes possible to complete the Sprint Goal (in some way) without completing all SBIs. This helps teams handle contingencies, and gives Developers flexibility in changing their work plan each day during the Daily Scrum. As an example: emergent impediments can threaten the Development Team’s delivery of the complete Sprint Backlog. In that case the team automatically resorts to the Sprint Goal as “Plan B” without expending long hours re-planning. A study performed by Carnegie-Mellon University  reports that teams that prepare ahead of time for interrupts handle them 14% better than teams that don’t prepare. Teams that prepare for interrupts complete an uninterrupted task interval 43% faster than teams that don’t prepare. It’s a mindset to prepare for unplanned things: when they happen, the teams can pivot to a new configuration to handle them, without external coaching.
It is theoretically possible to repeatedly achieve the Sprint Goal while completing only a fraction of the PBIs each Sprint. This should be uncommon, because the Sprint Backlog should align with the Sprint Goal; if not, there is a serious problem with the Value Stream.
Velocity helps teams understand if they are doing things right (with the assumption that doing things right increases your velocity.) The Sprint Goal helps teams ensure that they are doing the right things. It is about understanding the “why” of what the team is doing, so that they can keep focus on it when things change.
Jeff Sutherland adds that in addition to keeping the team focused it encourages Swarming: Can we get everyone working on one thing together? He relates: 
In Silicon Valley in 2007, Palm was working on a Web OS that was later acquired by Hewlett-Packard. Sprint to sprint the teams were doing well until they appeared to hit a wall in a couple of Sprints. PBIs were not getting finished. Developers were demotivated and going home early. I was brought in and got the Product Owners and ScrumMasters to spend an hour interviewing team members on why they were demotivated. We found that they did not understand the reason they were working hard on low level PBIs.
We spent an afternoon cleaning up the Product Backlog showing a clear linkage between high level stories and the decomposition hierarchy. As soon as the developers understood that the Sprint Goal was to improve performance of the Web OS by 10%, they were motivated to complete the low level stories and velocity went back up to normal.
Understanding why the PBIs are being implemented is critical for developers, particularly for expert developers who would prefer to go surfing if they don’t see the reason for their work.
The Sprint Goal is usually focused on increasing value of the product. Alternative Sprint Goals can also be defined like: doing all programming through pair programming, or showing up on time for the Daily Scrum every day.
Repeatedly driving to the Sprint Goal results in a happy team; conversely, the Happiness Metric can be an effective tool to define or suggest Sprint Goals.
In 2001 Ken Schwaber and Mike Beedle were the first to describe the Sprint Goal. 
 —. “Brain, Interrupted.” In New York Times, 5 May 2013, page SR12, http://www.nytimes.com/2013/05/05/opinion/sunday/a-focus-on-distraction.html (accessed 2 November 2017).
 From a personal conversation between Jeff Sutherland, Neil Harrison and James Coplien on 4 August 2013.
 Ken Schwaber and Mike Beedle. Agile Software Development with Scrum (Series in Agile Software Development). London: Pearson, Oct. 2001, p. 48
Picture from: Presentermedia.com.