Bernd
September 21, 2020
In the following I would like to take a closer look at the term "Sprint Goal" and search for answers to the following questions:
If you search for Sprint Goal in the Scrum Guide you will find the following description:
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.
The Sprint Goal is a common agreement of the Scrum Team what should come out at the end of the Sprint, also known as Product Increment. Usually this agreement is formulated as a short and concise text with the goal to give the team a guideline why they are building the Product Increment. By the way: the Sprint Goal is not optional, even if it is often misunderstood as such.
We usually create the Sprint Goal in the Sprint Planning Meeting. But of course it can also be formulated in advance.
The important thing is that the Sprint Goal is defined and accepted by the entire Scrum Team and that no Sprint should be started without a Sprint Goal.
If the entire team has agreed on a common goal, it can also be assumed that everyone is pulling in the same direction. But if the goal is only set by one person and the rest of the team more or less just nod off, this can have negative effects on the course of the Sprint. A typical example of this is when team members work on separate Product Backlog Items (PBI) in isolation rather than working together on the Sprint Goal.
The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.
If a Sprint does not have a Sprint Goal you could say that the goal is simply to work through all PBI of the Sprint - so why all the effort? Well, if a Sprint does not have a goal, it will be difficult for the team to keep the orientation. Which PBI should be transferred from the backlog to the Sprint? What do we want to achieve with this Sprint?
At the beginning of the Sprint it is often not clear how a PBI can be processed exactly and whether it is necessary to react to unforeseen problems or new requirements. The inherent complexity of software development requires an appropriate degree of flexibility. A good Sprint Goal enables the team to achieve this flexibility and thus helps to achieve the common goal.
In the following, let's take a closer look at the difficulties that can arise in regard to Sprint Goals. In our Sprints, for example, we often have the problem that several independent but usually smaller goals exist. Sometimes we even had the case that some of the team members didn't even know what the Sprint Goal actually is. We even got carried away to sprints without any Sprint Goal at all.
Fortunately we did not forget the three pillars of Scrum - transparency, inspection and adaptation - and learned from our initial mistakes.
The problem with composite Sprint Goals is that the team cannot focus all its energy on one task. Frequent context changes cause loss and the Daily Standup mutates into a status update where members announce what they have been working on and what they want to work on next. In short, it's more about 'me' than about 'us' - a successful collaboration towards a common Sprint Goal looks different.
With regard to the other problems, we have found that without a common Sprint Goal it is difficult to know when the Sprint was successful. Even if all PBI have been completed in the Sprint, there is no understanding that a common goal has been reached. Unfortunately too often unexpected problems occur, which lead to the fact that at the end of the Sprint there are still unfinished PBI. So if the goal is to work through all PBI, there is no reason to celebrate. However, if there is a concrete Sprint Goal, it is much easier for the developer team to decide which PBI are relevant for achieving the goal and which can be (temporarily) put on hold.
As a consequence we have established the following rules in our team:
When choosing the Sprint Goal we ask ourselves the following questions:
In our Daily Scrum meetings we
In conclusion I would like to say that what is described here is only a very small part of the way we currently apply Scrum in our team. Most important is to make things transparent, to question them and to optimize them together with the team.
Working as a software engineer for many years mostly in the JVM environment. Skilled in Scrum and Agile practices, currently scrum master of nerd.vision.
