Ralph Jocham
& Don McGreal

The term “Sprint Goal” is mentioned 27 times in the Scrum Guide. That marks it as an important concept in Scrum. Yet in practice, it is arguably the least-understood Scrum concept. As the Agile Manifesto says:

Individuals and interactions over processes and tools.

This mindset is a cornerstone of agility and how teams self-organize. However, self-organization doesn’t just happen on its own. Counterintuitively, it requires defined boundaries (rules) and a clear objective (vision). The Scrum framework is a simple set of proven rules to cope with complex problems. Ideally, a clear product vision is established before the first Sprint and continuously communicated throughout. The Product Owner is accountable for this and can leverage the Scrum cadences to reinforce it. A good vision provides a Scrum Team with focus and motivation toward a shared objective. A vision, however, cannot be reached in one step. There will be several smaller stepping stones along the way. These are Sprint Goals.

Arriving at one goal is the starting point to another.

—John Dewey

Sprint Goals are an often-neglected aspect of a Scrum implementation. When not completely ignored, the Sprint Goal often ends up as just a list of random items off the Product Backlog (Goal: “finish Story #23, #45, #48, #51, bug #88”). This isn’t a goal—it is nothing more than showing progress, staying busy, and prioritizing output over outcome.

This commonly happens because the Product Owner does not really “own” the product and is just being told what to do. As a result, the work taken on in a Sprint becomes a random smattering of requests from different stakeholders with no overarching direction.

Here are some tips for establishing a solid Sprint Goal:

• Imagine a Scrum Team member being stopped in the hallway by a stakeholder excited about the next Sprint Review and asking, “What will we see?” They don’t want to hear about the 12 forecasted Product Backlog Items. They want to hear a more concise, higher-level objective being reached.

• An interesting practice is for Scrum Teams to name their Sprints. Instead of naming Sprints with some arbitrary names (like with hurricanes), try naming Sprints after Sprint Goals, such as the “Registration Sprint.”

• Try asking the question, “How does this Sprint get us closer to our vision?” The answer is likely a candidate for a Sprint Goal.

• If there are multiple Sprint Goals for a Sprint, it is likely a sign that we aren’t thinking cohesively enough. Pick one of them and make that the objective. Because, “When everything is important, then nothing is.”

The Sprint Goal provides a North Star for the Development Team, for which they create their own plan: the Sprint Backlog. As the North Star remains fixed, the plan may need to be adapted to changing circumstances, allowing the Development Team to be even more self-organized. During the Daily Scrum, the Development Team assesses its progress toward the Sprint Goal, collectively updating the plan instead of having a tedious status report meeting.

On rare occasions, the Sprint Goal may become obsolete, yielding no value. In this situation, the Product Owner has the right to cancel the Sprint. The Scrum Team can immediately plan another Sprint with a new Sprint Goal.

Setting realistic Sprint Goals is paramount, as sprinting without a clear goal just gets you to the wrong location faster.