After reading fellow PST Piyush’s blog on the Sprint Goal and why he believes it is not defined as an artifact, I shared my own insights in a comment. Re-reading my own words, they seem potentially valuable as a seperate publication. So below is that comment, as a Blog.

The Sprint Goal is not an artifact in the Scrum Guide. Not because it is optional, or because it is less important than the other artifacts. In my understanding, the reason has everything to do with transparency and the way the Scrum artifacts support transparency in Scrum.

First we have to look into the artifacts: what are their key characteristics and main purpose in Scrum? 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.

Sprint Goal in red letters on white post it note, on a wooden wall with other post it notes around it
Sprint Goal example, source: https://www.flickr.com/photos/gdsteam/14060585631

As Piyush correclty states, the Sprint Goal is mentioned many times in the Scrum Guide. I have to disagree on one point with his blog post though. The distinction between the ’11 essentials’ and the rest of Scrum is not one of optionality, so the Scrum Goal is NOT optional (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. The Sprint Goal is a key element of Scrum and without it we cannot ‘do Scrum’ to full effect.

Finally, let’s conclude with 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.

So the Sprint Goal is not optional. If you struggle with defining valuable Sprint Goals, have a look at the scrum.org resources on Sprint Goals to learn more.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.