Why do you need a sprint goal?
A sprint goal is a short summary that represents the desired outcome of a sprint iteration.
The sprint goal is an integral part of the Scrum framework, but often it’s one of those things that teams forget to define during their sprint planning meetings. Some even wonder if you really need a Sprint goal when you already have a commitment.
Personally, in my years as a product owner with different development teams, I’ve had two vastly different experiences:
- The team is incredibly invested in creating a sprint goal and wants to experiment with finding the best sprint goal practices for themselves.
- The team doesn’t see the benefit in creating a sprint goal with an argument that it’s just a sentence describing the sprint.
Sprint goals are useful but often misunderstood. Let’s look at what they are, why they’re beneficial and how to create one.
What is a sprint goal?
A sprint goal is a short summary that represents the desired outcome of a sprint iteration. It is usually defined during sprint planning and is a result of collaboration between the product owner and the development team.
How do you create a sprint goal?
We start by having a reminder on our checklist during sprint planning meetings. I usually add a blank story in Jira to remind us to create it.
The sprint goal is created by all people attending the sprint planning meeting, and usually, a team member is writing it down as the whole team is taking ownership of a sprint goal. It should not be something mandated by a product owner, but it should be driven by PO inputs.
During the daily standup, the team sees the task in Jira for the sprint goal and in this way, it becomes a daily reminder of what we want to achieve by the end of the sprint.
Usually, in the teams I’m working in, we define a sprint goal based on stories that are coming from the value increments (Dynatrace term for large batches of work, bigger than epics — see SAI) defined by our business stakeholders. You group the items into specific deliverables and base your sprint goal on that whenever it’s possible.
Usually, in the teams I’m working in we don’t create a sprint goal based on all the user stories we committed to. We select the most important ones, the ones with higher priority, which means they will bring the highest value to our stakeholders.
It’s also very important to emphasize that a sprint goal doesn’t necessarily have to be a set of user stories, it can also be very urgent code optimization or fixing a nasty vulnerability.
Sprint goal example
What are the benefits of a sprint goal?
Adding a sprint goal to your sprint commitment has several benefits to communication and teamwork. Here are a couple of them:
Transparency
A sprint goal makes the direction of the team transparent, not only within the team but also to external stakeholders.
Focus
“Why is the sprint goal important? The stories will be ranked higher and we will work on them anyway!”
The whole team should be focused on stories related to the sprint goal. Not only development but also code reviews. If a story contributing to the sprint goal is waiting for a review, you should focus on that one rather than starting work on a new item from the sprint backlog. In this way, you can work towards delivering the goal on time. The same goes for business approval.
Teamwork
The sprint goal should be created by the whole team, so the whole team will be interested in achieving it. This is what builds the team. If only one person wants or creates a sprint goal, then it’s not really useful, since the rest of the team will not have the motivation to achieve it.
Decision-making
Having a sprint goal aids in decision-making. If you get a new ticket during the sprint that could affect the sprint goal, it will help you decide whether to pull it in or not. What’s more important? The sprint goal or a new requirement?
Commitment
In teams that I’m working in, committing to a sprint goal works better than only committing to a sprint backlog. It motivates us more towards achieving it.
Team’s roadmap
Having sprint goals also helps you with the creation of a roadmap for the team. You can split a large piece of work (value increment) into sprint goals.
Flexibility
You have 10 stories in a sprint, but only 4 are related to the sprint goal. If a bug comes up, you can pull out the stories that are not part of the sprint goal and deal with the bug, without affecting your sprint goal.
Conclusion
Sprint goals can be a bit confusing at times and many don’t understand why they’re needed if we have a commitment already. I’ve implemented sprint goals in some of the teams that I worked with and I know that it’s not always easy to do. And they’re not always perfect. Iterations lead to improvements and the same goes for sprint goals!
But I encourage you to try creating a Sprint Goal with your team in your next Sprint Planning. I really believe it helps the team focus and drive to achieve a common goal because I saw it happening.
Do you use Sprint Goals in your organizations? How do you create them? Let me know in a comment!
