Not every team benefits from a sprint goal.
Blasphemy? Perhaps.
But stay with me for a moment. I want to talk about what sprint goals are and how Scrum teams benefit from them. Then, I can explain why I still don't insist on them for every Scrum team.
What Is a Sprint Goal?
What is a sprint goal in agile processes like Scrum? The sprint goal is defined as the single objective for the sprint. A sprint goal is created and finalized by the entire Scrum team (Scrum Master, product owner and developers) during sprint planning, and helps communicate why the sprint is valuable to stakeholders.
Focusing on a single objective is a great idea. Development teams often benefit from the focus that a sprint goal provides.
Why Do Developers Need Sprint Goals?
The purpose of the sprint goal is to focus the team’s attention on what most needs to be achieved. I remember how vital this was in the late 1990s, the early days of Scrum.
Back then all teams did four-week sprints, no one did what we today call backlog refinement, and Extreme Programming hadn’t yet introduced the world to user stories.
Back then, teams would lose sight of what they were working on. I can clearly remember a mid-sprint discussion with a developer who said, “Remind me: what is it we’re trying to get done this sprint?”
In a long sprint with inadequately expressed product backlog items, this developer had quite literally forgotten whatever big goal the team was pursuing that sprint.
The sprint goal served to restore focus to that goal. I remember answering his question with, “increasing the average time spent on the search results screen,” which was the sprint goal (and is a good sprint goal example).
I spend a lot of time advising organizations to narrow their focus regarding what they will achieve, whether it be for a year, a quarter, or even a single sprint. It’s all too common for an organization or team to select a goal the way I load my plate at a buffet: a little of this, a little of that, some of the other.
Effective sprint goals encourage product owners to focus sprint plans on one specific goal for a product increment, so team members are always clear one what they are trying to accomplish in a time-bound iteration.
Why Are Sprint Goals Ineffective for Some Teams?
Yet with all the good sprint goals do, I admit I am a bit ambivalent toward Scrum’s sprint goal. I coach teams to try creating sprint goals, but I also let them know that not every team benefits from a sprint goal.
Why don't I insist on a sprint goal? Here's one big reason. Sometimes a sprint cannot be focused on a single objective. Some teams simply have multiple things that need to get done.
For example, consider a digital agency. A team there could be simultaneously building a new website for one client, doing some mid-sized enhancements for a second client, and making small bug fixes or edits for five additional clients.
How should their sprint goal be written? Should the goal focus on the new website, which will consume the most work during the sprint? Or should it focus on the small edits if those are for the company’s most important client?
Some teams merge all that into one goal with something like, “Finish the seven user stories we committed to.”
That might be a sprint goal, but it doesn’t benefit the team.
It doesn’t provide the clarity a good goal gives, and it’s too broad to focus the team on a single objective. Teams who write “finish the user stories we committed to” and consider that a sprint goal have effectively given up on sprint goals.
The Work of a Sprint Cannot Always Be Distilled into One Sentence
Here's the second reason sprint goals aren't always helpful. Sometimes, important things need to happen that are outside of a one- or two-sentence sprint goal.
In the early days of Scrum, sprint goals were usually used to evaluate the sprint—meet the sprint goal and the sprint was a success. Don’t achieve the sprint goal and the sprint wasn’t a success.
Looking at a sprint this way is incomplete.
Distilling an entire sprint to one goal has the same problems I have with to-do and personal productivity systems that tell me to make a list of the three most important things I need to accomplish each day.
Paying my mortgage is rarely the most important thing I need to do on a given day, but it does need to be done. Should I really put off paying my mortgage until the day I’m to be evicted for non-payment, at which point it truly is the most important thing that day?
A sprint is a complicated collection of work a team needs to accomplish; that work cannot always be encapsulated within a single goal.
Focus on Product Backlog Items When No Single Sprint Goal Is Possible
Imagine a golfer playing a typical hole somewhere right now. The golfer has the goal of getting the ball in the cup in four shots.
The golfer's first will be a drive from the tee. The second will be an approach shot, in which the player attempts to land the ball on the green. Next, the player will putt the ball, hoping to make it into the cup. But the player will likely need a second putt, which makes four shots overall.
Throughout this, the golfer is focused on a goal—get the ball in the cup in as few shots as possible. That goal is accomplished through a sequence of tasks—a long drive, a good approach shot, and a successful first or second putt.
I think a similar approach is appropriate for Scrum teams. The golfer can focus on successfully making each shot, knowing the shots will add up to the desired result of a good score on that hole. Scrum teams should be able to do the same: focus on the work, the sprint backlog items, that lead to a successful sprint.
This approach also supports a team that needs to work on things that cannot be contained within a single sprint goal, as was the case with the digital agency earlier.
In the same way that each of a golfer’s shots can be viewed as leading indicators of a good score on the hole overall, a team can see completing individual sprint backlog items as leading indicators of success toward achieving some informal goal.
My Recommendation on Sprint Goals
If sprint goals work for your team, by all means you should continue using them. If you hear “What is it we’re trying to get done this sprint?” from the team, sprint goals can help. And if you’re new to Scrum, you should absolutely try writing sprint goals for a few sprints.
But, if you’ve tried writing sprint goals and they just didn’t work for your team, then consider your effort a useful experiment, and proceed without them.
Let Me Know Your Thoughts
OK, let me hear it in the comments below. I know many people will strongly disagree. I’m quite open to changing my mind.
But let me know why I’m wrong—do us both a favor and make your argument something more than “because the Scrum Guide says so.”
Or if you agree, let me hear that I’m not alone in this opinion. And if you’ve tried writing sprint goals and found they weren’t for you, I’d love to hear more about that.
Please share your thoughts in the comments below.
