Sprint Goals Provide Purpose

Go Beyond Merely Completing Work Lists with a Sprint Goal

Research shows that people, whether acting individually or as a team, achieve more when working toward an objective that is specific, challenging, and concrete.^[1] For that, we need clear Sprint Goals.

A Sprint should be so much more than just completing a number of User Stories or fixing bugs. If your Sprints are merely about ticking off items on a scattered work list without having a shared understanding of why they’re important or what purpose they serve, your Development Team will struggle to keep focus in the short-term and will take longer to become highly effective in the long run. Sprint Goals provide purpose for the Scrum Team to work together effectively.

A Sprint should be so much more than just completing a number of User Stories or fixing bugs. If your Sprints are merely about ticking off items on a scattered work list without having a shared understanding of why they’re important or what purpose they serve, your Development Team will struggle to keep focus in the short-term and will take longer to become highly effective in the long run.

What does the Scrum Guide say about Sprint Goals?

As part of Sprint Planning it says:

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

As far as typical standards of the Scrum Guide go, this is clear 🙂. Key takeaway is that it’s about the value that the team will deliver in Sprint and it should help the stakeholders. This is going to be a handy measuring stick when we test bad Sprint Goals.

The Scrum Guide is also neatly answering questions that frequently come up in workshops:

When is the Sprint Goal set? During Sprint Planning.

Who is involved? The whole Scrum team, meaning Scrum Master, Product Owner, and Developers.

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 towards 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.”

Does the Goal Change in Sprint? It’s very hard to hit a moving target, so the answer is no, the goal does not change within each Sprint. However at the start of each Sprint, the team sets a new goal.

Are Sprint Goals optional? The Scrum Guide is clear on this, goals aren’t an optional part of Scrum. As we will see below, there occasions where goals aren’t practical, but they are still part of the game.

Why Do We Have Sprint Goals?

In Scrum, we ask a Team to undertake Sprint Planning to agree on what they will achieve in the next Sprint, based on their expected capacity. As an outcome of this, the team should leave their planning session with a clear goal.

This provides stable direction, with flexibility to re-evaluate work, throughout the Sprint. It is the WHY of a Sprint, establishing purpose and commitment.

By participating in setting a Goal, Team members experience a sense of ownership of it and gain a better understanding of the overall problem. On occasion, it also helps them find better solutions than originally planned because that overall perspective can help see things during the Sprint that aren’t obvious if looking only at the individual parts.

The Sprint Goal provides focus in Daily Scrum and an opportunity to refocus if the Sprint goes off-track. When distractions occur (e.g. new User Stories or other outside interference), a clear goal gives Team Members a way of saying “no”. They ask the question “Will this new thing help us get closer to the Sprint Goal?” If not, the distraction gets set aside and, if still relevant, considered in the next Product Backlog Refinement session.

Finally, jointly identifying and achieving shared goals is a key element for growing a group of people from a working group to a true team.^[2]

When Not to Use Sprint Goals in Scrum

Sometimes a team will have a Sprint of work with no focus. If this is rare, I wouldn’t try to set a Sprint Goal. Rather, I would acknowledge that, on this occasion, there isn’t a Sprint Goal. I have seen teams using Scrum to serve the needs of 4-5 distinct clients in a single Sprint. If their needs don’t have any overlap, then the team will not be able to set a Sprint Goal. Lacking a goal, this team will have a longer path to high performance. (I wouldn’t abandon Scrum altogether – see Limits of the Framework). However, the key point is that this should be a rare occurrence, not license to skip Sprint Goals normally.

Spotting Unhelpful, Meaningless Sprint Goals

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

• Fix 10 bugs – This lacks any sense of purpose. Why is it valuable to fix this batch of bugs vs any other bugs that are in the system?
• Finish 7 unrelated User Stories – Similar to the previous example, there is no sense of purpose.
• Complete the work assigned to the team in JIRA – Yes, this is remarkably anti-Agile and ineffective, however, I see it all too often. This implies the team is a group of robots whose job it is to move a task from one column on Sprint Backlog to another.

None of these examples help focus the Team. Nor do they clarify the value the team will deliver. The best test to spot unhelpful, meaningless Sprint goals is when the Stakeholders have no idea what they’re getting at the end of the Sprint.

How to Make Better Sprint Goals

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 – 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 – Implements a feature.
• Offer free shipping for orders over $40 – Tests an assumption that free shipping will increase the amount people spend per transaction.

Agile Coach 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?^[3] Then use that as 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.

Mark Levison

Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.