Should the sprint goal be an artifact in the scrum guide?

Each of the 3 Scrum artifacts are subject to inspection and adaptation. Is a Sprint Goal mutable and allowed to change?

Just my opinion, but I equate the term "artifact" with something tangible.

The Product Backlog is a physical list of items.   The Sprint Backlog is also a physical list of items.   The Increment is the physical assemblage of working software realized through the execution of one or more sprints.

The Sprint Goal, while extremely important (it is mentioned in the Scrum Guide 27 times) is an objective, a statement.   I'm not sure it rises to the tangible level of the three artifacts identified in the Scrum Guide.

I'm going to start by pointing you to this suggested change to the Scrum Guide from 2014.  https://scrumguide.uservoice.com/forums/241958-general/suggestions/5549865-include-the-sprint-goal-in-the-scrum-artifacts-sec

I completely agree with @Ian and @Timothy.  Artifacts are more tangible while being subject to inspection and adaption.  Look at how the word artifact is used in history and archaeology. A stone tablet that describes a rule or law is the artifact, not the actual text on the tablet. If a utensil if found at a archaeological dig and it has the word "spoon" on it, the actual item is considered an eating utensil. In both of my examples, the artifacts have been inspected and adapted over time. In my interpretation, the Sprint Goal is part of the Sprint and the Sprint is the artifact. Sprint Goal is just something that helps define the purpose of the artifact. 

Can't really add anything else to the comments above, I fully agree with what was said. 

Thank you all for sharing your insights. It gave me an other angle to look at my thoughts.

Each of the 3 Scrum artifacts are subject to inspection and adaptation. Is a Sprint Goal mutable and allowed to change?

Too often have I seen situations like: "Are we going to make it in this sprint?","Nah, we'll just change the Sprint Goal". It's like changing the destination of an airplane, mid-flight. Let's see how many passenger would like that.. 

I want to think out loudly here, I agree that the Sprint goal helps the Devleopment Team focus on an objective set for that Sprint. Further, my understanding is that the PBI's selected for a Sprint in order to achieve a Sprint Goal have to be coherent.

That leads me to ask the following questions,

Can we always have a Sprint Goal? What if we have work that is not coherent? Do we stop Sprinting? Wouldn't it be counterproductive if we force teams to have a Sprint Goal when it doesn't make sense? Nowhere in the scrum guide does it say the Sprint Goal is mandatory and perhaps (I'm assuming) this is what Sven de Koning is asking i.e. by making it an artifact, it would be mandatory.

On that note, even I am curious, if we don't have a Sprint Goal, does it mean we're not following Scrum?

Can we always have a Sprint Goal? What if we have work that is not coherent? Do we stop Sprinting?

There is no Sprint without a Sprint Goal, because then there would be nothing to sprint towards. Without a Sprint Goal it would be possible to observe a time-box or iteration within which work is performed, but it wouldn't be a Sprint.

On that note, even I am curious, if we don't have a Sprint Goal, does it mean we're not following Scrum?

Correct, because the framework only exists in its entirety, and although implementing parts of it may be possible the result would not be Scrum.

A Sprint Goal can be any coherence which gives the team a reason to work together. It might be a coherence which gives the selection of work a definite identity, such as a usable feature. On the other hand it might be as esoteric as Sprint Backlog priority, through which items of seemingly unrelated work are actioned by the team in a certain order so the best functional outcome is achieved.

Correct, because the framework only exists in its entirety, and although implementing parts of it may be possible the result would not be Scrum.

@Ian Mitchell, I agree with your points but what are your thoughts on this article regarding the Sprint Goal and how that relates to this discussion.

https://www.scrum.org/resources/blog/why-sprint-goal-not-essential-mandatory-artifact

Perhaps, the view point is from a Product perspective, what if we're dealing with Component Teams that are practicing Scrum. What if these teams have multiple projects (each project could relate to, or be a part of a different product). Can we not practice Scrum in such cases without forming a namesake Sprint Goal?

PS: I am genuinely seeking a healthy discussion and not pointing fingers, besides I'd like to be as clear on this subject as a practitioner and answer similar questions thrown at me, by my team.

what are your thoughts on this article regarding the Sprint Goal and how that relates to this discussion.

I’d agree with the follow-up part of the article in which it is asserted that the Sprint Goal is not optional. It is not a role, event, or artifact, but it is nevertheless one of the rules which bind the framework together.

Perhaps, the view point is from a Product perspective, what if we're dealing with Component Teams that are practicing Scrum. What if these teams have multiple projects (each project could relate to, or be a part of a different product). Can we not practice Scrum in such cases without forming a namesake Sprint Goal?

No. You’d be doing something else. That “something else” would not necessarily be wrong, and it might well be the smartest thing to do given the situation at hand, but it wouldn’t be Scrum. Moreover you’d gain nothing from calling it Scrum. Doing so would merely reduce transparency over what Scrum actually is.

In the situation you describe, I’d suggest that if the team were to find common purpose in working together during the Sprint, and a coherent reason for actually being a team, then there is a Sprint Goal somewhere. The challenge would lie not in determining its existence but in giving it expression.

There is no Sprint without a Sprint Goal, because then there would be nothing to sprint towards. Without a Sprint Goal it would be possible to observe a time-box or iteration within which work is performed, but it wouldn't be a Sprint.

@Ian Mitchell, okay, fair enough. Therefore the key points are: It is not Scrum if there is no Sprint Goal, It is not a Sprint Goal if there is no coherence.

To clarify and conclude, would it be fair to say that, As Sprint Planning is an immuatable event in Scrum, and as the Sprint Goal is a part of Sprint Planning (making Sprint Goal immutable too), therefore not having a Sprint Goal would result in not practicing Scrum?

To clarify and conclude, would it be fair to say that, As Sprint Planning is an immuatable event in Scrum, and as the Sprint Goal is a part of Sprint Planning (making Sprint Goal immutable too), therefore not having a Sprint Goal would result in not practicing Scrum?

Correct. I would encourage you to look at it this way: The Scrum Framework is characterized by the ability of a team to Sprint, and the rationale behind Sprinting is to meet a goal. The application of Scrum might therefore be said to stand or fall on the usefulness of meeting a Sprint Goal.