Quite a bit has changed between the 2017 & 2020 Scrum Guide with the introduction of the Product Goal emerging from the Product Backlog. In this article, lets take a look at the overall Scrum Artifacts section of the Scrum Guide.
Scrum Guide 2017
“Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.”
Scrum Guide 2020
“Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation. Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
● For the Product Backlog it is the Product Goal.
● For the Sprint Backlog it is the Sprint Goal.
● For the Increment it is the Definition of Done.
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.”
– Scrums 3 key artifacts are essential to Scrum.. The newly added Product Goal to the Scrum Guide gets prominence in its placement here with other specific Scrum Artifacts.
The Product Goal being in the Product Backlog and the Product Backlog emerging from the Product Goal makes logical sense when you dissect that word salad. Essentially I read this as the Product Backlog should only contain work that supports the Product Goal and nothing else. All other things should be cast out into the fires of Mount Doom… Ok nerd moment over… I like this in that context
The concern I have in practice is it being taken as a means to commit to long term planning. I would like to believe that is not the intention or how the Product Goal should be applied in practice. But this wording does give me pause with how this will probably be implemented in most organizations looking to utilize the Scrum Framework. More on this in the article I will write on the Product Backlog and Commitment to the Product Goal.
Then there is the all too familiar artifact of the Sprint Goal. The Sprint Goal is the single objective of a the Sprint. In my experience it is best when the Sprint Goal is identified and the Development Team then decides which Product Backlog Items to work on to deliver the Sprint Goal. Often times teams approach the Sprint Goal as if it is “Complete all of these things by the end of the Sprint.” This is not a good idea. It divides teams and drives silos. If this is happening, then it is time to have a discussion about prioritization and determining a Product Goal to focus the work on.
And that brings us to the Definition of Done. Of all the Scrum Artifacts that I may decide to write an entire article on, it would be the Definition of Done. The Definition of Done is what provides clarity to a Scrum Team of when something is of quality for the product. This is interpreted and used in so many different ways and that is why I will write an article on it. But for a sneak peak…
Different people from different walks of life think of a Definition of Done from the following perspectives.
- Done in the Sprint and Ready for UAT…. oomph
- Ready for Release…. oomph again, but a little less painful
- Ready for QA… wow, big dysfunction here
- Released to Production… YAY!
My bias is showing 
I will close out this article here and welcome feedback as always.
Chris Pipito 