At the end of every sprint is a goal that the Scrum team looks forward to achieving. After all, it’s what all the hard work, effort, time and commitment are for. As a rule of thumb, teams should work on a single goal at a time to ensure that everyone is focused and moves in the same direction.
You might be wondering – do you really need a sprint goal? You already have a product backlog after all. Why does it matter? The straight answer is YES. Software development, which is the basis of Scrum methodology, is a complex process. Even after creating the sprint backlog, there is a possibility that changes and revisions will happen along the way.
The sprint goal enables your team to focus on the objective. Furthermore, having a sprint goal promotes effective teamwork and commitment, makes it easier to gather feedback, and helps with stakeholder communication. The sprint goal also facilitates prioritisation especially when there are a lot of user stories and epics involved in a sprint. Additionally, it allows for an effective sprint planning session.
So what is a sprint goal and how does a Scrum team determine it? What if your team has multiple goals to achieve? How can you create an effective sprint goal?
In a nutshell, a sprint goal is the objective of the sprint – the time-box period in which a potentially releasable product increment is created. Put simply, it is the what the Scrum team plans to achieve at the end of each sprint. At a glance, determining the sprint goal is easy. However, it’s one of the few things that most Scrum teams struggle at. You’ve probably experienced this before – you and your agile team have come close to the end of the sprint planning and everyone is excited (and a little pressured) to start working on the Product backlog. And then all of a sudden, someone asks “What about the sprint goal?”. It seems like you’ve just had a reset button. Everything has to go back to step no. 1.
Then imagine this. Your team sprint contains stories for a number of clients and your products. At the same time, you take care of maintaining your company’s internal development tools. What if you have around 10 stories per sprint. How do you set a sprint goal that encompasses all stories?
Let’s try to settle these issues first by understanding what a sprint goal should look like.
A sprint goal is a short description (one to two sentences) of the Scrum team’s objective. Like any other goal, it must be S.M.A.R.T. (Specific, Measurable, Attainable, Relevant, and Time-bound). When the sprint goal is vague, it can be difficult for your team to determine whether you have been successful in achieving it. A well-defined sprint goal has the following patterns:
Apart from being clear and concise, the sprint goal should be measurable. This reduces subjectivity among the Scrum team members. Another important purpose of the sprint goal is that it provides motivation for running the sprint.
Let’s take a look at what vague and clear Sprint goals look like for an eCommerce website:
| Vague Sprint Goal | Clear Sprint Goal |
| Improve site performance | Reduce site downtime by 75% and eliminate unnecessary or redundant pages. |
| Enhance user experience | Streamline ordering process and add more payment options. |
| Develop the checkout process | Add shipping order form, request for order gift wrapping, and COD. |
At the end of each sprint, the Scrum team determines whether they have met their goal. However, the team needs to talk about the progress during the daily meeting to keep the goal visible to everybody.
Here are some tips to get to the ‘Done’ and meet your Scrum goal:
For a successful project, your scrum team has to go through several sprints. A lot of things can happen along the way – changes in the PBI, learning a new technology, sprint re-planning, iteration, and so on. Keeping the sprint goal relevant and meaningful to your Scrum team will keep everyone motivated to deliver high-quality work.
Many Scrum teams get confused with sprint backlog and sprint goal. Well, the sprint backlog items are what’s needed to reach the goal. Remember that.
Frustrating as it may seem, it happens. Again, during the course of the sprint, you might realise that there are user stories that you cannot implement or PBIs that no longer make sense. There are some things that you can do when things are not going as planned. One is to remove stories. Adding stories only makes the sprint more complicated. The only way possible is to remove stories. Check the stories that your team has not started yet. These are probably the least necessary and can be moved to the next sprint. Another thing, consider changing your ‘Done’ criteria. If you have a large story, consider splitting it into two or more stories.
As the Scrum Master, you may feel the need to interfere when your team doesn’t seem to be reaching the goal. However, failure is healthier than a forced success. Taking a retrospective analysis of the failed sprint might be a more meaningful step. There’s no need to be ashamed when you fail. Work hard with stakeholders to create a tolerance for failure. This should prevent your Scrum team from deviating from quality and adding technical debts.
We enable leaders to become highly valued and recognized to make an impact on the World by helping them to design Digital Product Companies that will thrive and nourish in the Digital Age, we do this by applying our own ADAPT Methodology®.