In the Scrum framework, a sprint goal is a one-sentence summary of the focus of the sprint or iteration.
Think about the sprint goal this way. Suppose you get in the office elevator, push the button to go to your floor and your boss’s boss—not your boss, but your boss’s boss—comes running up to the elevator and yells, “Hold the elevator!” They get in the elevator with you and say, “Hey, what are you working on this sprint?”
This person is just making friendly conversation and is also likely genuinely curious about what you are working on this sprint. But they aren’t looking for a deep dive.
I don’t know about you, but anytime I’ve had a conversation with my boss’s boss, I’ve had one goal: Get out of that conversation as quickly as possible!
So when the boss’s boss says, “Mike, what are you working on this sprint?” I’m nervous.
I don’t want to tell my boss’s boss everything in the sprint backlog. “Well we’re adding a field to the database. And I’m going to right-justify the dollar column on a report.”
This is way too much detail. The boss’s boss does not want to hear my sprint backlog.
The boss’s boss probably doesn’t even want to hear a list of all the user stories or job stories the team selected for the sprint. That’s also too much detail.
What the boss’s boss is looking for is a sprint goal: a one-sentence summary of what the team is trying to get done in the sprint.
So when asked what we’re working on, the sprint goal gives me an easy way to reply: “This sprint, we’re implementing the basic shopping cart functionality, including add, remove, and update quantities.”
When Should a Sprint Goal Be Created?
At the beginning of each sprint, when the Scrum team is gathered for sprint planning, the product owner proposes a sprint goal for the upcoming sprint. Toward the end of sprint planning, the development team and product owner revise the sprint goal as necessary to reflect what the team committed to creating.
To use the previous example, suppose at the beginning of sprint planning, the product owner says: “This sprint, I’d like to implement the basic shopping cart functionality, including add, remove, and update quantities.”
Suppose the team then looks at their capacity or their historical velocity to decide what product backlog items they can commit to. During this process, they make some decisions affecting the sprint goal. They come back to the product owner and ask if they can change it.
Maybe, for instance, they say they aren’t sure they can deliver the “update quantities” story this sprint. So they propose an alternate sprint goal: “This sprint, we’re implementing the basic shopping cart functionality, including add and remove quantities.”
Goals Tend to Be Related from Sprint to Sprint
The sprint goal changes each sprint. So next sprint, during sprint planning, the Scrum Master, developers, and product owner will select a new sprint goal that describes the work of the upcoming sprint.
And then, next sprint, when the boss’s boss asks me what we’re working on, I might say, “Well, we’re working on trying to finish the checkout process: update quantities, pay for an order, pick shipping method, things like that.”
Notice that the two example sprint goals I’ve used are related: the product increments are both in the shopping cart or checkout area of the system. Team members tend to have a gradual migration through an area of the product. They don’t usually work in one area, and then a totally different area in the next sprint, and then back to the first area.
From sprint to sprint, the work tends to be related. And people can see how the team’s sprint goal has evolved through parts of the system.
Why Are Sprint Goals Helpful to the Business?
Scrum’s sprint goal is meant to be a one-sentence summary that helps those outside the Scrum team understand what the team is trying to accomplish in the sprint. Teams create sprint goals to provide greater context for the work being undertaken and because it helps stakeholders understand why they’re being asked to participate in a sprint review.
That means a sprint goal is good to include in your email inviting people to a sprint review. Sharing the sprint goal then helps stakeholders know if they should attend.
Why Do Developers Need a Sprint Goal?
We’ve established that sprint goals can help developers if they’re ever stuck in the elevator with a curious executive. But beyond that, are sprint goals helpful to developers? I’d say yes, for many of the same reasons that estimates are helpful to developers. Sprint goals keep the team focused, help team members see the big picture of what they are trying to accomplish, and increase a team’s standing with stakeholders as dependable partners in product creation.
If a team usually (shouldn’t be always) achieves their sprint goal, stakeholders learn they can count on that team to deliver what they say they will.
One Sign Your Sprint Goal Isn’t Helpful
One more thing I want to share about sprint goals is that some teams write horrible sprint goals. It’s not really their fault.
Think about a team that is working on six or seven completely unrelated things. I’ll see this a fair amount in digital agencies. A team in that situation may do work for five or six clients in a sprint. One client might need a bunch of work this sprint. A second client needs a fair amount, and then there are three or four that just need a tiny bit of work in the sprint.
It would be hard in those types of situations to turn the goals of multiple people into a one-sentence sprint goal.
Some teams try but end up with sprint goals such as, “Finish the seven user stories we committed to.”
“Finish the seven user stories we committed to” is not a good sprint goal. A sprint goal has to be higher-level than that.
Yet if you’re working on things for seven different clients and you’ve got one user story from each, you probably can’t write a very good sprint goal.
Sprint goals are very helpful for some teams, but not for all teams in the world. That’s why, contrary to the Scrum Guide, I consider sprint goals an optional part of Scrum. I absolutely want you to try sprint goals to see if they work for you. But if they don’t work for you, that’s OK!— especially if you’re in a situation like I just described.
