The commitment to finish everything from the backlog can endanger your real goals
Commit to the Sprint Goal instead
Commit to the Sprint Goal instead
Does this discussion during the Daily Scrum look familiar to you?
“How many points do we still have to burn?”
“21. We burned 68 until now.”
“This means that we have to push hard to make this commitment. We can’t afford another mess-up like the last two Sprints. How shall we divide the work?”
If it does, ask yourself: “Am I committing to the right things?” The team in the example is fixed upon delivering everything from the Sprint Backlog. This is an anti-pattern.
![Paper contract chained to a lock Paper contract chained to a lock](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fc5d94d40-6799-4d28-86e4-da1410e566c1_800x533.jpeg)
Teams should not commit to the Sprint Backlog. They should commit to meeting the Sprint Goal.
Commitment
One of the Scrum Values is commitment:
“People personally commit to achieving the goals of the Scrum Team.” — Scrum Guide 2017
Completing all the items from the Sprint Backlog is NOT one of the goals:
“The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.” — Scrum Guide 2017
Instead the Scrum Team commits to:
Delivering a “Done” increment;
Meeting the Sprint Goal.
A team may have other goals too, but these goals are directly related to working in a Scrum environment.
The Sprint Backlog is a reflection of how the Development Team believes it can deliver the Increment and reach the Sprint Goal. New insights will lead to changes to the Sprint Backlog. Therefore it can never be a commitment.
If you focus on completing the Sprint Backlog without reflecting if it needs to be amended to reach your goals, you are setting yourself up for trouble. You may build the wrong thing altogether.
A Sprint Goal to commit to
Now that we have established that a team commits to a Sprint Goal — not the Sprint Backlog — we can also easily identify ineffective Sprint Goals:
a goal listing the backlog items like “Deliver items A, B, C and F” — too specific with no wiggle room;
a goal like “take the next step with our product” — too generic, leaving room for all kinds of interpretations;
no goal at all!
A good Sprint Goal is something that the team can commit to, focus on:
“Create a proof of concept that shows that our technical approach works”;
“Improve performance of product X by 10%”;
“Create a first user interface to verify functionality and look-and-feel”.
A great Sprint Goal also leaves room for the Development Team to determine the ‘how’. In a Sprint Planning, the team comes up with the best version of ‘how’ based on the information available at that point of time. During the sprint, as more information is discovered, this ‘how’ can change as more is learned.
End note
Commitment is one of the Scrum Values. This word is often applied to the Sprint Backlog. But committing to the Sprint Backlog is an anti-pattern.
A Scrum Team should commit to creating a “Done” Increment and meeting the Sprint Goal instead. The Sprint Backlog exists to serve this. It reflects the team’s current insights on how to meet the Sprint Goal and where they are on the road towards it. It can be changed if new insights emerge.