As many Professional Scrum Trainers have experienced, there is always a good discussion around the Sprint Goal. A similar discussion recently led me to address this not so well understood aspect. Of-course, I cannot say on behalf of Ken and Jeff, why they kept Sprint Goal out of the 11 essentials, I would like to present my thoughts on the same.
Before that, let us start by understanding what the Sprint Goal is, so that we all are on the same page.
Sprint Goal:
An objective that is crafted by the Scrum Team during the Sprint planning session, which provides an overarching guidance to the Scrum Team as to WHY they are investing their time, money and effort into the Sprint.
From the Scrum Guide:
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 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.
Why the Sprint Goal is not an artifact among the 11 essentials:
Scrum, is not prescriptive and the Scrum Guide reflects the same philosophy. To start doing Scrum the 11 elements - 3 Roles, 3 Artifacts and 5 Events are good enough. Again, as Scrum thrives on self-organizing teams, allowing them to decide on what serves their purpose and maximizes the impact of Scrum in their context, is of more value than telling the teams what needs to be done.
The Scrum Guide has evolved over time. The earliest edition of the Scrum Guide was bit more prescriptive. It cites the chicken and pig story, talks about burndowns etc. As a result, there were some anti-patterns observed. Teams fell into the trap of following only things mentioned in Scrum Guide. The idea, however was never that. The idea was to create self-organizing teams that could find what works for them, inspect and adapt.
Sprint Goal has been an integral part of Sprint Planning since the beginning; the Scrum team crafts it and it is one of the outcomes of Sprint Planning. If we read through the Scrum Guide, Sprint Goal/Goal is mentioned about 37 times which is equal to number of mentions of Product Owner and is more than the number of mentions of Scrum Master. If we just look about for the specific word Sprint Goal it is mentioned more than Sprint Backlog itself. This clearly indicates and emphasizes that Sprint Goal is an integral part of the Scrum framework; however it is left for the Scrum Teams to discover its importance and use it to their advantage.
Not making it mandatory also allows teams to be flexible and decide whether it makes sense for them to have a Sprint Goal or not. What if, the Sprint Goal is made mandatory as an artifact and the teams start defining the scope of the sprint as a goal (I have seen many teams doing that) to be achieved to be in adherence to Scrum; what purpose would it solve?
Remember, Scrum is not about being prescriptive, it is about providing an environment where self-organizing teams can thrive and choose what works best for them. And for that matter, the 11 essentials are minimal but sufficient.
Conclusion:
Although, the Sprint Goal is not defined as an artifact within the Scrum Guide it is an integral part of the Scrum framework. It provides an overarching objective for the Scrum Team which helps them to focus "WHY" is the team invested in the Sprint.
Read More about Sprint Goal:
https://www.scrum.org/resources/blog/11-advantages-using-sprint-goal
https://www.scrum.org/resources/blog/scrum-trenches-sprint-goal
https://www.romanpichler.com/blog/sprint-goal-template/
An additional perspective from Sjoerd (though I am not sure why his comment was marked spam and removed):
I would like to add another probable reason for the Sprint Goal not being an artifact in the Scrum Guide.
It has to do with the nature and reason of the artifacts that are defined. All three artifacts (Increment, Product Backlog & Sprint Backlog) exist to give transparency to the Product development. 'Done' value in the Increment, Potential future value in the Product Backlog & potential value under development in the Sprint Backlog (past, future, present).
Each of these three artifacts is not just a static artifact. To be as maximally transparent as possible, they are so called 'living' artifacts. They are subject to change at any moment, to reflect the newest insights (Backlogs) or newest 'Done' parts of work. Every new insight that impacts an aspect of value should be reflected in an updated artifact for maximum transparency.
This is where a major difference is, both to the Sprint Goal (as well as the Definition of Done). The Sprint Goal & DoD are not living artifacts. Each is stable during Sprint. The Sprint Goal is NOT something we change upon new insights and is not there to make transparent a current state of something. It is a concept to create transparency, yes, but a stable sort of transparency so the Scrum Team and Stakeholders know what the goal of this Sprint is, and can adapt their plan (reflected in the Sprint Backlog) to best reach this goal. If the Sprint Goal were a (living) artifact, we would be aiming for a moving target, or not knowing where to aim since it is always changing. By being stable, it creates a boundary within which we can Inspect & Adapt the current Sprint's efforts.
As you correctly state, the Sprint Goal is mentioned many times in the Scrum Guide. I have to disagree on one point with your blog post though. It is not optional. The distinction between the '11 essentials' and the rest of Scrum is not one of optionality (again, same for the DoD). Without a Sprint Goal we cannot properly Inspect & Adapt the current progress of the Sprint nor evaluate the Sprint properly during Sprint Review. Without a Sprint Goal we fall prey to 'just getting work done' instead of delivering value.
Finally, that is what the Sprint Goal should be making transparent: the Value of this Sprint. Why do we choose to conduct this Sprint? What is the value we seek to create? Why did we select these items from the Product Backlog and not others? How will we know whether the Sprint was successful in the Sprint Review? Those are the questions we seek to answer with the Sprint Goal and if we have no clarity on those aspects of Product Development then we are missing a key element of Empiricism, and missing a key Inspect & Adapt opportunity in Scrum.