Last but most definitely not least, we come to the Scrum Artifacts as defined in the 2020 Scrum Guide. This section has also been reduced in size while seeing some pretty significant changes to long-standing Scrum definitions. So let’s dive right in.
One of the major changes to the definitions of the Scrum Artifacts is the pairing of each Artifact with a concomitant Commitment that ensures the Artifact is used properly and contributes to the Empirical approach and upholds the Scrum Values for the Scrum Team and its stakeholders
Product Backlog/Product Goal
The definition of the Product Backlog is now significantly simpler than in any previous edition of the Scrum Guide. The Product Backlog is now defined simply as an emergent, ordered list of everything needed to “improve” the product – whatever that might mean. Now don’t get me wrong, I’m a big fan of seeking out simplicity, but this one goes some distance too far for me, removing helpful guidance that has helped make the Product Backlog an effective Artifact for Scrum Teams for decades.
On the plus side, the 2020 definition of the Product Backlog specifically calls out the use of the ongoing activity of Product Backlog Refinement, whose purpose is to break Product Backlog Items into small, precise items that the Developers can implement during a Sprint. This section also specifically designates the Developers as the sole source of sizing estimates for Product Backlog Items. The only role for the Product Owner is this estimating activity is to ensure that the Developers understand any potential trade-offs and to help them decide which option to pursue. Otherwise, the Product Owner stays out of it.
The new Commitment that pairs with the Product Backlog is the Product Goal, which describes the desired future state of the product and serves as the long-range target that the Scrum Team uses to plan and deliver Product Increments effectively. Crucially, the Product Backlog emerges to define what is needed to fulfill the Product Goal.
This is a nice addition to Scrum practice because it formally addresses one of the major complaints about Scrum, which is the apparent focus on short-term goals at the expense of broader product-level thinking, both in terms of the business objectives and architecture and design of the product itself.
The Product Goal is the first item added to the Product Backlog. The rest of the Product Backlog emerges to satisfy the Product Goal as the Scrum Team and stakeholders learn more about what is needed to produce a successful product.
Finally, the Scrum Team is not allowed to move on to a different Product Goal until they have achieved or abandoned the existing Product Goal. This is an important practice as it prevents Scrum Teams from losing focus when the organization attempts to push multiple products onto a Product Backlog. There can only ever be one Product Goal in the Product Backlog.
Sprint Backlog/Sprint Goal
There is less new in this area since both of these items have existed for some time in Scrum practice. The new definition provides nice clarity on the importance of having a Sprint Goal that drives the creation of the Sprint Backlog and the delivery of work during a Sprint. This section of the 2020 Scrum Guide reiterates that the Sprint Plan contains the why, what, and how of the Sprint and is driven by the commitment to achieving the Sprint Goal. Otherwise, the established practices around making adjustments to achieve the Sprint Goal continue to apply.
Increment/Definition of Done
A major simplification in terms is the removal of “Potentially Releasable Product” as a modifier in front of “Increment.” The new definition of the Increment ties it directly to the Product Goal, as each Increment must demonstrate progress toward achievement of the Product Goal. Each Increment must be completely done and add measurable value to the product. In a new clarification, the Scrum Team may produce multiple Increments each Sprint and can even release one or more Increments during the Sprint. The Sprint Review is still necessary to gather data about the sum of all the Increments produced during a Sprint (if more than one), but the Sprint Review is specifically defined as NOT being some kind of gate preliminary to the release of one or more Increments. This has long been standard practice so in that sense the Scrum Guide is catching up with the real world of Scrum practice.
An Increment cannot be considered complete until it meets the Definition of Done – hence the Definition of Done is the commitment that pairs with the Increment. The Definition of Done describes in detail the quality measures that must be met for the Product to be successful.
The Developers are “required” to meet the quality standards defined in the Definition of Done, meaning that no outside force can compel the Developers to abandon their Definition of Done, nor can Developers simply ignore the Definition of Done if it is inconvenient, hard work, etc. When more than one Scrum Team works on the same product, all Teams must agree upon a shared Definition of Done that controls the quality of work across the product.
That’s it for this time. Until we meet again, stay safe, stay focused.