The Sprint Goal, as defined by the creators of Scrum, is a selection of product backlog items that form one coherent feature, which helps a development team to work together rather than pursue separate initiatives. Ian Mitchell, a writer on agile software development, summarizes the usefulness of the Sprint Goal by writing the following statement on a blog post:

What we are getting at here is that the whole purpose of a sprint is to meet a Sprint Goal, and Scrum is framed to support sprint-based delivery. Take away the Sprint Goal and the rationale for using Scrum disappears with it. You might as well operate on the basis of continuous flow. Without a Sprint Goal to meet, sprint backlogs can serve no useful purpose.

The Sprint Goal is a description of the coherent increments that will be delivered at the end of the sprint and it provides guidance to the development team on why it is building an increment and how it should do so. If the development team discovers that they won’t be able to deliver that coherent feature during the sprint, they can negotiate the scope with the PO.

We can go even further by describing all the advantages of a well defined Sprint Goal and how it helps to get things done effectively. It helps …

• The team to understand the purpose of their work beyond the description of individual PBIs, which stimulates intrinsic motivation and compliance. This leads to better implementation as the team can keep the big picture in mind. A well known man built an empire on this concept alone.
• To keep the team focused on a small objective and avoid the negative impact of context switching. It can be seen as mini projects. These are clearly achievable multiple goals instead of a big one that is divided into chunks used to fill sprints (Waterfall disguised as Scrum). Focus is a very important concept to understand when you work with knowledge and creative workers (in the case of the vast majority of people in software development); it is probably the most important thing to work on in order to deliver value and quality to your customers.
• The team to collaborate on a single objective with required flexibility and empowerment (cohesion vs individualism). This leads to better shared responsibility as the success of the sprint will be evaluated based on whether the goal has been met, instead of counting all the individual tasks that can lead to individual developer comparison in the worst implementation of Scrum. This helps in getting cohesion which is the most important factor for a high performing team.
• The PO provide clear value beyond the selected product backlog items (PBI) and therefore improve prioritisation. This helps getting a realeasable product increment at the end of each sprint, which is the whole point of agile software development.
• The PO to communicate on progress based on working software, instead of a percentage of a list of individual tasks that means nothing to the customer. This also helps to create a valuable roadmap to communicate to users.
• The PO to get structured feedback from each meaningful increment instead of individual tasks. This provides the next sprints with new insights which automatically leverage the power of Scrum or any other iteration based framework.

The Sprint Goal, when properly used, is a proof that Scrum is understood and correctly implemented. Together with the (potential) release of a new product increment, this makes the Scrum Sprint really useful. Therefore, this is the first thing I check when I’m asked to audit an existing Scrum implementation. Sadly, this is the most overlooked artifact of Scrum, so if you begin a new implementation, start with the sprint goal and explain why it’s useful.