Commitments and their meaning in SG 2020

Commitments: a little new and a little old

In 2020, the Scrum Guide 2020 introduced the concept of commitments, one for each artifact (physical things). They are:

• the Definition of Done
• the Sprint Goal
• the Product Goal

Of the three, Sprint Goal and Definition of Done have been around for quite some time, but not called commitments.  Product Goal is new.  

But what is a commitment? A dictionary search provides at least one good definition: a pledge or promise - akin to an obligation (https://www.dictionary.com/browse/commitment). A commitment can be a binding promise, contract, or a firm decision to do something (https://dictionary.cambridge.org/us/dictionary/english/commitment). If you miss a commitment, you have not done what you promised and expected. Missing a commitment is a failure of duty. These are strong words with a solid direction to meet the commitment.

 

What does the Scrum Guide say?

The Scrum Guide describes a commitment as

“Each artifact is committed to ensuring it provides information that enhances transparency and focuses progress.  These commitments reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.” (https://scrumguides.org/scrum-guide.html)

In a nutshell:

• the Definition of Done is what the team commits to producing an increment
• the Sprint Goal is what the team commits to fulfilling during the sprint
• the Product Goal is what the team commits to fulfilling for the product

 

Commitments are the WHY behind the artifact

These three commitments become the reason behind their related artifacts. For a great explanation of the importance of “why,” see Simon Sinek’s “Start with Why: How Great Leaders Inspire Everyone to Take Action.”

Scrum Commitments make it clear to the team members why they are working on a particular artefact and how this work contributes to the common goal the team is working towards.

 

Let’s take the Sprint Goal as an example. 

Developments commit to completing the work selected for the sprint backlog in some (old and/or incorrect) interpretations of Scrum. Some managers push developers to commit to the actual plan devised from the tasks within the sprint backlog. Committing to the PBIs is predictive but committing to a plan to implement those PBIs is significantly more predictive.

During sprint planning, PBIs are selected from the product backlog and added to the sprint backlog, and then a plan to complete those items is created - often in the form of tasks. The command and control approach infers that if the team is having difficulty meeting the “committed work,” it’s up to management to pressure them to get the work on time and within scope.

 

The power of commitments

Shifting the plan to focus on goals leads to a lot more flexibility and shared accountability. If the team cannot complete a selected PBIs during a sprint or cannot follow the plan for a selected PBI, the commitment is to the Sprint Goal, not the details. The team can work with the product owner to determine a better way to meet the Sprint Goal - perhaps by modifying the original plan or intent of the work in the Sprint Backlog.

The Scrum Team commits to the Sprint Goal, not toward the selected work; just don’t take the chosen work during sprint planning as a suggestion. The sprint backlog should contain a good selection and meaningful plan but allow flexibility and agility.

 

Summary

Commitments in the Scrum Guide 2020 separate analysis (why) from design (how), leaving the analysis (why) in the hands of the team during planning and the design (how) to be determined via actually creating the product.  

The Sprint Goal helps achieve flexibility in the Sprint. As for the Product Goal, understanding why the product exists and its future reason for existing can help the product owner manage the product backlog. The increment is not an increment until it reaches the Definition of Done commitment.  So the Definition of Done provides quality constraints for the product.

The commitments are not optional.  If you’re not using them, you are doing a version of Scrum, not the Scrum defined in the Scrum Guide.  Surely your goal is not to be “proper” with Scrum, but if you deviate from the Scrum Guide, you run the risk of missing out on effective agility.  Leaving out one or more commitments will have a ripple effect in all of the events and may lead back to a predictive, command and control approach to product development.  Don’t do it. 

See my classes at www.suscheck.com