The Serious Scrum community discusses the Sprint Goal
![Rugby field with goal posts and low sun depicted as a ball through the posts. Rugby field with goal posts and low sun depicted as a ball through the posts.](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F30e71d46-c606-4b80-adf2-c025ab548c4c_800x400.jpeg)
Serious Scrum has a flourishing on-line community on Slack. Apart from writing and editing articles we are very much engaging in discussions about Scrum. Often these discussions are really exiting and insightful because a topic is approached from many angles by people with all kinds of experience and knowledge.
Pieter V came with a great suggestion to bring these discussions to a wider audience. Firstly they show how great our community is, but more importantly they can be very interesting for other people interested in Scrum.
In this first article — which I created in together with Pieter V — the Serious Scrum community is discussing the importance of the Sprint Goal.
It all started when Ionut-Adrian Bejenaru posted the following question:
“Folks — what makes the Sprint Goal imperative for a successful Scrum implementation?”
Thomas Owens was the first to respond:
“First, a snide response: The Scrum Guide says that you must have a Sprint Goal. So if you don’t, you aren’t doing Scrum, and therefore can’t have a successful implementation of Scrum.”
“Now, a real answer: I don’t think it’s imperative for agile approaches, but it does help. It helps the (development) team to self-organize around an objective and make trade-offs without needing to go and ask for clarification.”
“If there’s a goal or objective that can be worked toward for a given iteration, the team can adjust what/how they are working to be able to meet that objective, regardless of what specific work items get done and delivered.”
Ionut-Adrian Bejenaru:
“Thank you Thomas. Then we can say that the Goal enables self-management, focus, collaboration and perhaps autonomy. What else makes the goal important in product development?”
Thomas Owens:
“I think that sums it up. It’s all about self-organization (and self-management), focus, and autonomy. It’s a technique to give the team direction and guidance that they can self-organize around. I don’t think, broadly speaking, that it’s important in product development.”
Ionut-Adrian Bejenaru:
“Hmmm — so it isn’t really important what the goal is but merely its existence is important.”
Thomas Owens:
“Yeah. At the product level, you tend to have a scope and a vision that helps define what the product is or does and helps you decide what types of work should be done or not done. The Sprint Goal is that, but for a single iteration.”
“Having a Sprint Goal is far more important than the specifics of what it is. But I’d also want to make sure it’s reasonable — if your goal is not achievable, it may do more harm than good if it demoralizes the team. Achieving goals makes people feel good.”
Ionut-Adrian Bejenaru:
“Would you say that the Sprint Goals does not necessarily need to build-up cumulatively, towards the product vision? And that Sprint Goals are more a technique to optimize the team workflow?”
Dante Peralta:
“I agree with Thomas in that to have a successful Scrum implementation all aspects defined in the Scrum Guide must be present. The Sprint Goal is a very challenging concept in practice. In my experience teams always try to define it as a sum of Product Backlog Items (PBI) that implements a part of the product. The problem with this is that when a PBI cannot be Done (as we are working in a complex environment), there’s no room for negotiation because any change will endanger the Sprint Goal (Scrum Guide: no change can endanger the Sprint Goal). The importance is to allow that flexibility when things get difficult. The whole Scrum Team agrees to a Sprint Goal so even if a PBI is missing, the Product Owner receives a valuable potentially releasable increment.”
Dirk:
“First, having a sprint goal prevents Development burnout (yes — burnout, not burndown). Working in a Scrum team can be tiresome when item after item passes you by. At the end of the day you don’t even know which or how many tasks have been done. Doing this sprint after sprint can really be tiresome. Remembering the sprint with a goal isn’t.”
“Secondly, when a Product Owner merely presents some backlog items to the development team, the team wouldn’t have the chance to pick other related stuff further down in the backlog, or (god forbid) make their own suggestions.”
“While some interruptions during the Sprint are ok (need to be), interruptions preventing focus for 14 days are not. When you don’t have a goal except for “do these stories” you can’t distinguish between “ok” and “not ok” interruptions.”
“Moreover, a Sprint Goal can be challenged on a high level, a technical requirement not so much. Also a Sprint Goal can become a shared goal for a team, while a specific backlog item cannot.”
Ionut-Adrian Bejenaru then summarizes the discussion so far and poses a further question: “By now we can all agree that the Sprint Goal does wonders within the Scrum team — but is this the goal of Sprint Goals?”
Max Heiliger:
“Yes. The Sprint Goal is there to foster courage, commitment and focus. I have also noticed that Sprint Goals are excellent “canaries”, that is, early warning signs of an agile implementation slowing down or going astray. If you can leave out the Sprint Goal (implicit and explicit) and nothing changes, chances are there is an issue with your organization.”
Ionut-Adrian Bejenaru:
“And if the goal is to have Sprint Goals with the aim to create self-managed, focused, courageous, autonomous teams — what do we do with such teams?”
Max Heiliger:
“They continue to use Sprint Goals if they see the value, or figure out a better way to work that suits their team.”
Ionut-Adrian Bejenaru:
“And what would be the Goal of such team to keep working together?”
Willem-Jan Ageling:
“A Sprint goal is pivotal to avoid falling in the feature factory routine, where the team is ticking off items without understanding why. A Sprint Goal helps the Development Team to understand what needs to be achieved, leaving them the freedom to determine how. Scrum is a framework to create complex products. With that you can’t assume you know exactly how you create the increment when you start the Sprint.”
“Teams that wish to move away from determining a Sprint Goal either don’t work in a complex environment, don’t understand Scrum or work with something similar like doing experiments, trying to answer a question.”
Ionut-Adrian Bejenaru:
“Nicely said Willem-Jan: “A Sprint Goal helps the Development Team to understand what needs to be achieved”. Can we then say that the aim is to exert learning and to determine if we make progress towards building the right thing? If there is no goal to support these facts, how would we gauge if we’re productive and heading the right direction?”
Willem-Jan Ageling:
“I believe that’s it, Ionut. The Sprint Goal supports empiricism.”
Maarten Dalmijn:
“I actually believe the best explanation for this is from Dan Ray in his article:
The Lie of the Iron Triangle
What an old waterfall chestnut tells us about Agile.medium.com
“In Scrum everything is fixed except scope. There is a fixed budget (same team price after the Sprint has started), fixed quality (Definition of Done), and fixed time (the Sprint). That’s why you need a Sprint Goal.”
“Let’s say you plan 10 Product Backlog items, but it turns out to meet the goal you forgot some backlog items. You can add these items during the Sprint, as it is necessary to meet the goal. This means scope is flexible. Removing items is just fine as well, as long as you can still meet the Sprint Goal”
This concludes the discussion as it happened last week. As you can see this discussion with its many contributors and approaches on the topic of the Sprint Goal brought us a lot of insights. Here is a summary of the ideas that were brought forward:
The Scrum Guide says that you must have a Sprint Goal.
It helps the (development) team to self-organize around an objective and make trade-offs without needing to ask for clarification.
The Sprint Goal enables self-management, focus, collaboration and perhaps autonomy.
You have a scope and a vision at the product level. The Sprint Goal is like that, but for a single iteration.
Having a Sprint Goal is far more important than the specifics of what it is.
If your Sprint Goal is just a sum of Product Backlog Items there’s no room for negotiation because any change will endanger this Sprint Goal.
Mindlessly finishing Backlog Items doesn’t give a team a sense of purpose.
A Sprint Goal fosters courage, commitment and focus in the team.
Sprint Goals are excellent “canaries”, that is early warning signs of an agile implementation slowing down or going astray.
A Sprint Goal helps the Development Team to understand what needs to be achieved, leaving them the freedom to determine how.
The aim of the Sprint Goal is to exert learning and to determine if we make progress towards building the right thing.
The Sprint Goal supports empiricism.
In Scrum, time, quality and cost are fixed, but not scope. That’s why you need a Sprint Goal.
What are your thoughts? Please share them with us on our Slack Channel!