I have a confession to make. For many years, I worked with teams where we never set a sprint goal. This was just not part of my initial Scrum training (from my Scrum Master/QA Engineer who had been a part-time Scrum Master for 4 months). While my teams didn’t define a sprint goal, they still delivered value. But still, something was missing. We were missing a connection to a larger purpose. We were missing a singular focus. We were missing the raison d’etre for the sprint.
With a well-crafted sprint goal, the team has a singular focus. While crafting the goal, the team takes a moment away from the tactical, day-to-day development and delivery of software and have an opportunity to connect the tactical items defined in the user stories back to the overall vision and direction for the product being built.
A sprint goal is one, singular statement that defines what the team will work towards during the sprint. It is one logical thing, and one thing only. The sprint goal becomes the most important thing to accomplish. It is outcome driven - stating the outcome we hope to achieve in the sprint, not the tasks that we hope to complete. If the team is faced with prioritization questions during the execution of the sprint, they should first ask which item is necessary for the sprint goal.
As with most things in life, it’s as much about the journey as it is the destination. Crafting a sprint goal to set a team’s singular focus might be hard. Good! It should be hard, because by choosing our focus, we must discuss trade-offs. By focusing on one thing, that means we may not achieve this other thing over on the side. As the team discusses what the focus is and isn’t, they practice the hard decisions they may need to make later in the sprint when the sprint goal begins to slip out of their reach.
I’ve seen some teams treat sprint goals as a list of outcomes the team hopes to achieve. They treat the sprint goal as ‘sprinkles’, an after thought garnish to the team’s planning process that scatters the team’s focus. Take a moment and say the phrase ‘sprint goal’ as fast as you can 10 times. What did you hear? I hear the word ‘sprinkle’, and that’s exactly what you get when you rush through the creation of a sprint goal.
Example
Let’s dive into an example of what a decent sprint goal looks like, a good sprint goal, and a ‘sprinkle’.
For our example, let’s say we are building an online bookstore. The site is functional, but we are overhauling some elements of the site, including the search functionality so that we serve up more accurate results. The team chooses the following stories for their sprint, in priority order:
- Search on Book Title
- Search on Author
- Search on Description
- Bug Fix: Correct Book Review display issue when reviewe leaves 0 stars
- Allow user to report offensive Book Review
- Allow user to view list of all of their reviews
- Allow user to edit a review
A Decent Sprint Goal
Complete Book Search Feature
This is ok, but it is output focus (complete the task), and not outcome focused (what value we are delivering). This Sprint Goal is better than a ‘sprinkle’, and does tell the team where their focus is, but it doesn’t connect back to the vision of the product.
A Good Sprint Goal
Enable shoppers to search for a book so that they find a book to click on on the first page of results 80% of the time
This goal does not call out specific stories, but it is specific about our aim - we want accurate results delivered and have included our measure for success.
A ‘Sprinkle’
Complete the following items in the sprint
- Search functionality delivered
- Fix Book review display issue
- Begin Book review enhancements
What is wrong with this sprint goal? First, it avoids any hard decisions. In fact, were there any decisions made when the team crafted this sprint goal?
Second, there are 3 focuses here, not 1. This team will find itself split on 3 different areas throughout the sprint. They will likely start all 3 sprint goals on day 1 of the sprint and keep a scattered focus throughout.
Finally, this sprint goal is essentially a copy of the sprint backlog, only summarizing a few stories into a couple of bullet points. If most ofthe information is already captured in the sprint backlog, what value does the sprint goal have?
Conclusion
Sprint Goals, when used well, are a powerful tool to bring a team together. It forces tough conversations. It reminds us of our overall purpose and direction. It gives us a target beyond ‘complete this story, move on to the next’. Sprint goals should not be sprinkled onto a team’s process as an afterthought or written such that a team’s focus is sprinkled around the backlog. It should be a singular, well crated goal that drives the team forward.