Originally posted on https://www.debooij.training
About 10 years ago I became part of a Scrum Team. It was my very first experience with Scrum. During these first few months I never heard anyone mention "Sprint Goal". I didn't even know it was something that existed. Now, 10 years later, I conclude it is time to dedicate an entire post to the Spring Goal. And I will make a case why the Sprint Goal should take center stage in any Sprint.
What happens when there is no Sprint Goal?
Well, that's quite easy to answer. When there is no clear goal to achieve with the current Sprint, the plan for the Sprint - the Sprint Backlog - implicitly becomes the goal. This is what I see happening very often with many Scrum Teams. The consequence is that it's very likely the Development Team focuses on getting all items from the Sprint Backlog "Done" within the Sprint. And that getting the whole Sprint Backlog "done" equals a successful Sprint.
Why is this a problem?
For a couple of reasons:
- If you believe that you can predict upfront what will lead to valuable outcomes, why do you use Scrum in the first place? Why pursue agility?
- When new insights emerge during the Sprint, there is probably little to no space do deviate from the plan since completing the plan has become the goal. It's likely the Sprint Backlog won't be adapted after Sprint Planning and stays more or less the same throughout the Sprint.
- If you focus on getting activities done without a clear understanding of what you want to achieve overall, every small decision becomes arbitrary. I experienced this when I was a Product Owner. The Development Team consulted me for every small detail that they didn't foresee but were confronted with during the Sprint.
- There is a risk that the Development Team as a collective feels limited ownership and accountability for the value they deliver together. There is a chance that every single member focusses on their own activities and tasks instead of what they can do together to produce valuable outcomes for their end users and other stakeholders. You can often observe this symptom during a Daily Scrum; when individual Development Team members tell what they worked on and going to work on with little to no interaction between the Development Team members. It has a negative impact on self-organization.
- Without a Sprint Goal, it's difficult to provide transparency to stakeholders why we are doing this Sprint, and how it connects to the Product Vision and business strategy.
- And when it's not clear what we want to achieve, how do we know what success looks like?
- and the list goes on and on...
I just want to illustrate that the Sprint Goal is the beating heart of the Sprint. And taking it out causes many different disfunctions to surface. And I see way too much symptom fighting and too little understanding of the causes. I use plural here because next to the absence of a Sprint Goal there might be other causes contributing to these symptoms.
Reasons why a Sprint Goal doesn't seem to work for you
When this topic comes across in my training courses, I often get the feedback "we cannot define a Sprint Goal because we work on many different things at the same time. It's impossible to distill one single goal". And this is what I love about Scrum. When it seems difficult to apply it properly, it's an indication there is an opportunity to improve. I go deeper into this topic in my post Don’t blame “agile” for existing problems. The Scrum Values provide guidance here. The following questions could help create a better understanding of the real problems you need to address:
- What are possible reasons we have little focus in what we do?
- What price do we pay for this limited focus?
- Imagine we would be able to focus an entire Sprint on one single need or problem. What benefits might that bring?
- What stops us from doing this?
- And what are we going to do about it?
The most common reason why it is hard to define a meaningful Sprint Goal is a lack of focus.
Blog post: Are dependencies dictating your Product Backlog?
Getting the Scrum facts straight
In a Sprint we have a fixed goal - the Sprint Goal - and a flexible plan - the Sprint Backlog. During Sprint Planning, the Development Team creates the Sprint Backlog. It is their plan to best meet the Sprint Goal within the current Sprint. When new insights emerge, the Development Team adapts the Sprint Backlog accordingly to ensure it remains the Development Team's best plan to meet the Sprint Goal. And at least every Daily Scrum, the Development Team inspects the progress towards the Sprint Goal and adapt the Sprint Backlog when it makes sense.
"The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.
As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint."
Scrum Guide
How do you write a good Sprint Goal?
As a guideline, I use the principle that a good Sprint Goal is a concise oneliner that describes why we are doing this Sprint in terms of value to our stakeholders.
Some examples to illustrate:
- Reducing the effort it takes to complete a successful submission of workflow "A"
- Enable check-in on a mobile device
- Collect feedback from our end users
- etc.
It is a good idea to make them more specific than I did here. For example:
- Complete a successful submission of workflow "A" within 2 minutes
Although this is quite specific, it still leaves a lot of space for the Development Team to figure out how to achieve this and to self-organize around this goal. The most important thing is to experiment with Sprint Goals, inspect, and adapt. Discover what works for you and what doesn't.
Bear in mind though, that during Sprint Planning, the Development Team pulls Product Backlog Items to the Sprint Backlog based on the order of the Product Backlog and what they think is a realistic forecast for the Sprint. So don't abuse the Sprint Goal to push more work into the Sprint. However, the Scrum Guide doesn't describe explicitly how and when the Sprint Goal should be created, other than that it is crafted during Sprint Planning by the Scrum Team.
What is your experience with Sprint Goals?
What are your thoughts on and experience with Sprint Goals? Please leave them in a comment below.
And if you would like to learn more join me at one of my upcoming training courses.