Why must we define a Sprint Goal for each Sprint?

Question

As a Scrum Team, we are committed to deliver Product Backlog items per the Product Owner's priority. The team doesn't understand why we should define Sprint Goals. How does that help?

Answer 1

TL;DR

You must define a Sprint Goal for each Sprint for two primary reasons:

1. It's required by the framework for both philosophical and pragmatic reasons as described in the subsequent sections.
2. It provides a focus for limited resources within Scrum's iterative methodology.

While it is possible to be agile without a central coherence as provided by the Sprint Goal, the result isn't Scrum. Furthermore, Scrum (or other coherence-based methodologies) may not be the right fit for your organization or project if Sprint Goals can't be constructed or honored.

Why the Sprint Goal is Needed

The Sprint Goal is an essential element of Scrum, which is primarily (although not exclusively) a product development framework. As such, it is intended to iteratively deliver features, as opposed to other frameworks which focus on other mechanics such as throughput or cycle time. Because of this development-centric focus, work is intended to be batched into cohesive themes for each iteration.

If you are "doing Scrum" without setting well-defined Sprint Goals, then you can't actually claim to be following the Scrum model. This isn't just a philosophical distinction. The Sprint Goal is essential to a properly-implemented Scrum framework. The Scrum Guide defines the Sprint Goal as follows:

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

In other words, the Scrum Goal provides:

1. A measurable objective for the time box.
2. Context (and therefore scope) for the Product Backlog Items developed within the time box.
3. Context for the daily Scrum, without which it typically devolves into status reporting.
4. A baseline expectation for measuring variance.
5. The essential criterion for cancelling a Sprint due to superseded business goals, adaptive learning, or as an escape hatch for errors in Sprint Planning or delivery.

In my professional experience, without the Sprint Goal as a core element, Scrum often fails to provide expected gains in productivity.

Reasons People Try to Skip Sprint Goals

Teams that don't implement Scrum Goals often do this for some common reasons, including:

1. They aren't really doing iterative time boxing.

   If you aren't respecting the time box, or the team is doing demand-based work rather than building features within a time box, then having an over-arching goal probably doesn't make sense. However, that's often a "project smell" that Scrum is the wrong framework for managing the project.

2. The team, and especially the Product Owner, isn't leveraging the framework.

   Scrum is meant to deliver a product in thin, preferably-vertical slices of functionality. However, there's a lot of effort that goes into prioritizing Product Backlog into features and related stories that fit within a single time box. It's hard, so skipping the Sprint Goal is essentially a cop-out.

3. The 100% utilization fallacy and lack of prioritization.

   Some teams, when under pressure to deliver more work in less time, discard the Sprint Goal in order to work on multiple objectives at the same time or to avoid slack in the process. However, deliberate disconnection of a central coherence and multiple priorities competing for limited resources are sure-fire ways to torpedo any possible efficiencies from an iterative methodology.

I'm sure there are other reasons, too. The point here is that, unless you're using Scrum for something other than product development (e.g. administrative or service-oriented programs), failing to define and defend a central coherence is not only canonically-wrong from a framework perspective, but frequently detrimental to the project's allocation of focused resources. This notion of focused (but limited) resources is absolutely essential to the iterative paradigm, and underlies virtually all agile and traditional methodologies. Scrum just makes it much more explicit through the use of the Sprint Goal.

What Next?

If a team is struggling to define coherent Sprint Goals for each iteration, the Scrum Master can and should educate the team (and the organization!) on the importance of setting and adhering to the goals. This should be done not only because it's important to the Scrum framework, but because it is ultimately important to the product development effort.

If the Scrum Master isn't able to provide this level of guidance, or doesn't have sufficient influence within the organization to enforce the framework's essential components, then hiring an Agile Coach to advise the team would be the logical next step. The coach can help the team improve the implementation of Scrum, or suggest alternative frameworks that can succeed without an explicit central coherence for each time box.

Answer 2

A sprint goal is a short description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner. So it helps the PO and the team to choose the right set of tasks to work on.

For example the sprint goal is to enhance the application response rate to be one minute instead of five minutes.

So by knowing this you'll know as a team which tasks to work on to deliver the required goal.

Answer 3

Also the sprint goal is essential to be able to say that the sprint is done. Is the sprint goal not achieved the sprint is not done and therefore the sprint failed. In addition to that the sprint goal id necessary to be able to determine if the sprint has to be stopped. When the sprint goal becomes obsolete the sprint can be terminated.

Answer 4

The concept of "sprint goal" in scrum is relatively new to me, but it sounds like it's there to help the stakeholders and product owner conceptualize the work they want to see in the sprint, and to communicate that concept to the engineering team. My team does not use this concept, but it sounds like it's more useful in larger organizations with smaller teams that can be devoted to a single-minded pursuit over a given sprint. For a team that is responsible for all of the organization's engineering work (like my team), this concept is probably not helpful.