Commitments
In the 2020 Version of the Scrum Guide, the commitments were introduced for each artifact. These then became an element of Scrum; in that they need to be used to gain the maximum value that the Scrum Framework offers. They were always part of a Professional Scrum approach, now there is a clear connection of these commitments to the artifacts. They increase transparency, and the focussed delivery of Value. Each of the commitments now clearly support and sustain an artifact.
Product Goal
The why of the Product Backlog
“The increment is a step toward a vision or goal. “
Scrum Guide 2017
In the previous versions there was an acknowledgement that a goal is being strived for. With the clarification of having a commitment to the Product Goal there is the recognition that the Scrum Team should be striving to deliver the value of a goal. This applies in every domain, and helps everyone associated with the Scrum Team to understand the direction and intent of what they are working towards.
When our team has an understanding of why they are working together, that will empower and enable them individually and collectively to make the best decisions to deliver the highest value for the organisation. The intent of many decisions will be already understood, as they are connected to the Product Goal.
The understanding of how the Scrum Team will achieve the Product Goal is described in the Product Backlog. The activity that the Scrum Team needs to deliver, the plan on how the team forecasts they will achieve the goal is communicated in the Product Backlog.
The process of breaking down and developing a better understanding of bigger ideas is still called refinement. This critical activity remains open to the team to determine exactly what details need to be added, and how they will go about building and sharing this understanding. Our experience suggests that having a way of describing the Product Backlog Items in the next Sprint should be more detailed. Having a clear description and order, as well as an appreciation of whether they can be completed within a Sprint is helpful.
Who makes the Product Goal?
The Product Owner is accountable for the development and communication of the Product Goal; however, they would work with the Scrum Team and stakeholders to make sure that it is clear and easy to understand. There is no single definitive way to do this, it depends on your context and domain.
The simplest test is when you share the Product Goal with someone, they understand what you are striving to do, and see the value in working towards it.
A good team has Product Goal, a great team has a powerfully inspirational Product Goal.
What happens when the goal changes?
This may well happen, as the world becomes increasingly more connected the amount of Volatility, Uncertainty, Complexity and Ambiguity (VUCA) will grow. The reason that the Product Backlog is dynamic and changing is to allow Scrum Teams to adapt when their context and understanding changes.
You can only have one Product Goal, so when the current Product Goal is achieved a new one would be created. If there is a significant change in context and the current Product Goal has not been achieved then the Scrum Team would replace the Product Goal with a more fitting one. If the Product is no longer relevant in the market (remember floppy disks, video cassettes, etc), then the organisation would either pivot or fold.
If this change to the Product Goal happens in a Sprint it remains in the authority of the Product Owner to cancel the Sprint if the goal of Sprint no longer aligns with the updated Product Goal.
How frequently should you change the Product Goal?
The Product Goal is a strategic vision, and the frequency of update will reflect your situation and context. If the market and Product is fairly stable it may be every quarter, if the situation is rapidly changing then more frequently.
Definition of Done
The Increment is releasable
The intent of Scrum has always been to deliver a Done increment to unlock the business value.
Professional Scrum is, and always has been, ruthlessly focussed on helping the Scrum Team deliver a Done Increment. This is the moment when the work is completed to the standards of the organisation. This means meeting the quality measures required for the product.
This will depend on what your Scrum Team is doing. Now that Scrum is being used in so many domains it is prudent to allow the Scrum Team to craft an appropriate definition.
Make sure you have created a Definition of Done before you start your first Sprint.
No, really, what should go in the Definition of Done
The Definition of Done should be clearly understood by the Scrum Team, so that there is no confusion or ambiguity. The state of a Product Backlog item should always be known, either not Done, or Done.
Any organisational standards – these are the bare minimum. Using the Scrum framework is not an excuse for non-compliance. The key is to focus on the outcomes of these standards. This should include any compliance or regulatory requirements. Having worked in some safety critical industries these are essential to be able to release.
No, really, what could be in the list
The intent of the latest Scrum Guide is to be less prescriptive. What makes your product valuable and able to share with the consumer?
If your Definition of Done is not very stringent, it may allow for Technical Debt to build in your product. Technical Debt is seen when making changes to your Product becomes increasingly difficult.
When are we Done?
When a Product Backlog item meets the Definition of Done, the work would be integrated into any previous Increment and you are Done. If this is the start of a new Product, at the time that your first Product Backlog item meets the Definition of Done. Voila! You have just created your first increment.
And, if we aren’t Done?
Don’t serve raw chicken!
Any work that does not meet the Definition of Done it should not be shared in the Sprint Review, and returned to the Product Backlog. It will then be considered with the rest of the Product Backlog in future Sprints.
Sprint Goal
The why of the Sprint Backlog
The Sprint Goal is the objective for the Sprint. It is a commitment by the Developers to the intent of the Sprint and provides flexibility in terms of how they achieve it. This encourages the sense of purpose for the Sprint, and the focus for the Scrum Team to work together to achieve the delivery of the Sprint Goal.
The Sprint Goal shouldn’t change during the Sprint. During the Sprint if the work emerges to be different then the scope of work in the Sprint Backlog can be renegotiated collaboratively by the Product Owner and the Developers.
Example – Catch up with Friends
You agree to meet with some friends to catch up. That is the goal. The details of what you do when you catch up is the Sprint Backlog. You meet in town, and the café you planned to meet at is closed. You replan. You go to a restaurant and have a meal instead.
The goal stays the same, the plan changes. No drama, no hassles, a collaborative conversation and focus on the goal. That is the intent.
Who makes the Sprint Goal?
The Scrum Team make the Sprint Goal collaboratively in Sprint Planning. Once created it is added to the Sprint Backlog to focus the work during the Sprint. The Sprint Backlog is a visible real-time description of how the Developers plan to achieve the Sprint Goal.
When Sprint Planning is over the Sprint Goal is fixed.
Change the Sprint Goal?
Uh – no.
This is the reason that a Sprint could be cancelled. This is the authority of the Product Owner. If it is necessary change the work in the Sprint. Cancelling Sprints is painful and expensive; however, if you need to, do so.
The three Commitments – boosting artefact transparency
These three commitments were introduced in the 2020 Scrum Guide to remove some of the ambiguity around whether a team using Scrum should use these elements. It is now clear; they are part of Scrum.
The commitments have been introduced to bring focus on the progress of each of the three artefacts, and to increase transparency.
The Product Goal brings greater transparency to the Product Backlog.
The Sprint Goal brings greater transparency to the Sprint Backlog.
The Definition of Done brings greater transparency to the Increment.
How can they help you improve your Scrum use?