Mark Levison

A Sprint should be so much more than just completing a collection of user stories or fixing bugs. If your Sprints are merely about ticking off items on a scattered work list without purpose or direction, your Development Team will take longer to become highly effective and your work will have less value.

The research¹ is clear:² people, whether acting individually or as a team, achieve more when working toward goals, and goals themselves benefit from being specific, challenging, and concrete.

In Scrum, we ask a Team to set a goal for a Sprint as an outcome of Sprint Planning. This provides stable direction, with flexibility to reevaluate work, throughout the Sprint to preserve and make the best progress toward the Sprint Goal. It is the why of a Sprint, establishing purpose and commitment.

A clear Sprint Goal helps the Development Team maintain a solid understanding of that why and what they’re attempting to deliver. By participating in setting the Goal, they have a sense of ownership and, on occasion, it helps them find better solutions to the problem than originally planned. The Goal provides focus in the Daily Scrum and an opportunity to refocus if the Sprint goes off track. Finally, the Goal is a key element for growing a group of people from a working group to a true team.

In my experience, most Sprint Goals are not clear. Some poor examples that I’ve seen are:

• Fix 10 bugs.

• Finish 7 unrelated user stories.

• Complete the work assigned to the team in Jira. (Yes, this is remarkably anti-Agile and ineffective; however, I see it all too often.)

None of these examples help focus the Team, nor do they provide clarity on what they’re seeking to achieve.

So, what makes a better Sprint Goal? A good Goal answers questions such as: Why is it worthwhile to undertake this Sprint? Are we attempting to solve a problem? Are we implementing a feature or clarifying an assumption?

Improved versions might include:

• Reduce the shopping cart abandon rate from 50% to 30% by improving usability and performance. This solves a problem. We’re losing sales because we have a poor checkout experience.

• Add filters to the existing product search results so that buyers spend less time finding items that meet their needs. This implements a feature.

• Offer free shipping for orders over $40. This tests an assumption that free shipping will increase the amount people spend per transaction.

Should the Product Owner set the Sprint Goal? No. It’s good for them to go into Sprint Planning with some business or product objective in mind, but it’s through negotiation with the Development Team that the actual Sprint Goal emerges, as all grow toward a shared understanding of what is desirable and achievable in the Sprint. “Achievable” means possible to accomplish while upholding the quality agreed to in the definition of Done.

Bob Galen suggests³ that you imagine crafting an email to invite your whole company to your Sprint Review. What will you put in the subject line and first few sentences to entice them to attend?

That’s your clue for your Sprint Goal—the shared understanding, created between the Product Owner and the Development Team, of the desired outcome of the Sprint.