Leaving Sprint Planning without a Sprint Goal

In the story at the beginning of this chapter, during sprint planning, the team worked through the unrefined product backlog, trying to define scope. And then as they executed the work, they struggled to find answers about the scope while also building the product. There was no overarching objective for the current sprint. The product owner and development team frequently argued when a sprint produced an unsatisfactory outcome.

This is precisely what happens when a Scrum team doesn’t create a sprint goal during sprint planning. The development team has no clear purpose, and the product owner doesn’t have an expectation they can discuss with the development team and stakeholders. In the words of one frustrated developer, sprints become “hamster wheels.”

Joe asks:

What’s a sprint goal?

A sprint goal is a singular objective that describes the purpose of a sprint. It outlines a business need or feature for the product. It’s the Scrum team’s connection to the customer during a sprint. It creates transparency and is a scope-negotiation tool between the development team and product owner. As long as you have a sprint goal in place, then the product owner and development team have clear expectations of each other.

So what makes for a good or bad sprint goal? Consider the following sprint backlog for a team that’s expanding an online pet supply store:

The various “Add Digital Payment” items used to be a single item, but during the sprint planning event, the development team split it into four separate PBIs because they agreed that they can implement each one independently. Along with these four items, the dev team forecasts that they can also complete a bug fix and add an additional feature that would expand on shipping system integrations.

The product owner has a hypothesis that the addition of digital payments is something that will be widely used by customers. The product owner thinks customers will be eager to use digital payments, so she put that item at the top of the product backlog prior to the sprint planning.

Here’s one possible sprint goal for this sprint backlog:

“Continue adding features and fixing bugs for the pet supply store.”

Can a development team rally around delivering this goal? Does it describe an overarching purpose to do the sprint? Does it describe a path to the customer? Not really. It’s rather generic and could be applied to every sprint for this team. It doesn’t tell the story of a value proposition that the team is working to complete, nor does it provide an elevating objective for the sprint.

Here’s another possible sprint goal for this backlog:

“Add digital forms of online payment.”

This is a far superior sprint goal. It’s vague enough that it doesn’t limit scope changes yet explicit enough that it provides the development team with an elevating goal to self-organize around. There are additional product backlog items in the sprint, but none as important as implementing digital forms of online payment. This helps the development team understand how to organize and plan their work.

To further illustrate the power of a good sprint goal, let’s say that halfway through the sprint, the development team realizes that integration with the digital payment systems is much more complex than they initially thought. The development team tells the product owner that they’re confident they can complete one digital payment system, and asks which one to prioritize. The product owner says to focus on Apple Pay. The second example of a sprint goal is flexible enough to allow for these kinds of course corrections.

Joe asks:

Who creates the sprint goal?

The sprint goal is an output of sprint planning. It’s a collaborative effort between the product owner and the development team. As the Scrum master, you should help your team create a sprint goal.

The work that we do is complex and no matter how meticulously we plan a sprint, the plan will change. Implementations can be harder (or easier) than expected. We need to afford ourselves the opportunity to be agile, and sprint goals like the second example do just that.