From useless to unifying — how changing our approach to Sprint Goals improved our Scrum team
The importance of setting a sprint goal is emphasized heavily in the Scrum Guide. It is the commitment that the development team makes when completing the sprint backlog. Whilst I theoretically understood the importance of the sprint goal, my work with a scrum team at Babylon Health gave me experience of the impact of good sprint goals.
Back in 2020, I began working at Babylon Health and inherited one scrum team working on improving the technology for communicating to members. Happily, one of the rituals the team already had was setting sprint goals. The goals were there to track progress towards the value being delivered, and help the team focus rather than attempting to just get all the tickets to Done.
The team was cross-functional, with specialists in different programming languages, and so were often working on different tickets. As a result, the team would set 2 or 3 goals for the week about progressing each of the initiatives being worked on. The team thought carefully about setting achievable but ambitious goals they could get done if they focussed and had limited distractions.
We began to notice that the team ended up regularly missing these goals. They often made significant progress towards the goal, but did not complete what they had intended to do within the sprint. After a few months of this repeated pattern, we set up a review to understand why this was happening and what were the impacts. We did an analysis of our success rate, and to our astonishment, the problem was worse than we thought — just 30% of goals were completely within the sprint! There was a clear need for a change of approach.
In this review, we understood that sometimes engineers felt conflicted by having two goals they could work on. It meant a lack of focus of the team working together, with engineers often focussing on one of the goals to the detriment of the other. In fact, this revealed that the team were not effectively working as a team to achieve a single goal as is one of the key valuable elements of Scrum.
In the spirit of empiricism, we ran a one month experiment on having a single sprint goal. Even if others were working on different items as was required due to our support requests, we would have a single goal to focus the team as the number one strategic priority. The effect was transformatory.
In terms of measurable impact, the team hit 80% of their goals for the next five sprints — the only miss being due to an unforeseen incident derailing priorities. But the effects were much more significant than a greater number of goals met. The team began collaborating more during the sprint and working together on the goal. The product manager and myself became more focussed in setting the right goals to move the product towards delivering more customer value. Sprint Planning became more effective as the team worked out how to achieve the goal.
We still have some progress to make to ensure the sprint goals become more output focussed and the team focuses even more on working on the sprint goal and not other work. But I hope this practical example shows how changing to a singular sprint goal can help drive the right behaviours in teams and unlock the value of Scrum.
