Why I Don’t Emphasize Sprint Goals

I admit to feeling some ambivalence toward Scrum’s sprint goal. I coach teams to try creating sprint goals, but I also inform them that not every team benefits from a sprint goal.

Blasphemy? Perhaps.

The sprint goal is defined as the single objective for the sprint.

I love that. 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…

But 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 doesn’t help. 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 Goal of the Sprint Goal

The goal 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.

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. There are often important things that need to be done that are outside a one- or two-sentence sprint goal.

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.

Focusing Instead on Product Backlog Items

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 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

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.


101+ Ways to Get Inspired About Agile

101+ Ways to Get Inspired About Agile

Get this free PDF of inspiring agile quotes when you sign up for Mike’s weekly tips email.

Get weekly tips from Mike Cohn

0

Posted:

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at [email protected]. If you want to succeed with agile, you can also have Mike email you a short tip each week.