Commitments and forecasts when using Scrum

A regular topic in my Scrum courses is commitments and forecasts. Time and again we uncover significant misunderstandings about what a Scrum Team can commit to and what it cannot.

The most common example is the Product Backlog items the Developers take into a Sprint. Somehow they turn into a hard commitment. If not all of them are Done, something must be wrong, and the Scrum Team must have failed.

This post sets out to debunk that one myth, and to recap commitments versus forecasts across the evolutions of the Scrum Guide.

What commitment actually means

A quick online search gives two definitions of commitment:

• "The state or quality of being dedicated to a cause or activity."
• "An engagement or obligation that restricts freedom of action."

These are quite different. The first is about dedication: "I couldn't fault the team for their commitment." The second is a future state we are promising to achieve. A guarantee.

With that distinction in mind, here is how the Scrum Guide has treated commitments and forecasts over time.

Scrum Guide 2010

"The Team has committed to a Sprint Goal, and to these Product Backlog items."

The first version of the Scrum Guide does describe a firm commitment that every item taken into a Sprint will be Done. If they are not, there may be an issue worth exploring. Have we failed as a team because we did not achieve everything we promised?

Interestingly, most teams using Scrum today have never read this 2010 version, yet many still hold the strong belief that every selected item must be Done or something has gone wrong. If that belief did not come from the guide, could it come from the culture and behaviours already present in the wider organisation?

Scrum Guide 2011

Thankfully this use of commitment did not last long. The 2011 update changed it:

"…the Development Team forecasts the Product Backlog items it will deliver in the Sprint."

"…Development Team to forecast what it believes it can do in the upcoming Sprint."

"Commit is now forecast."

Early on came the realisation that, when dealing with complexity and a significant number of unknowns, it is simply not possible to perfectly plan everything to be done, even within a single Sprint.

Scrum Guide 2016

The 2016 version introduced the Scrum Values, one of which is commitment.

Here it means, but is not limited to, committing to being professional, to quality, to helping and supporting each other, to working on tough problems, and to our goals. It touches both meanings of the word: dedication and effort, and the promise to focus on delivering future goals.

Scrum Guide 2020

The three commitments arrived in 2020.

Each of the three artefacts now has a commitment that brings transparency to it. For the Increment it is the Definition of Done. For the Product Backlog it is the Product Goal. For the Sprint Backlog it is the Sprint Goal.

Developers adhere to the Definition of Done. That is completely non-negotiable. A firm commitment. A promise.

The Product Goal and Sprint Goal help the Scrum Team focus on progress towards a future state, which serves empiricism. A Scrum Team commits to one Product Goal at a time, and either achieves or abandons it before moving to the next.

The Sprint Goal is created by the whole Scrum Team during Sprint Planning. The whole team, not just the Product Owner. The Developers then commit to creating at least one usable Increment by the end of the Sprint that achieves that Sprint Goal. That is their commitment. They are not committing to completing every Product Backlog item taken into the Sprint. As the Sprint progresses and more is learned, the Sprint Backlog emerges. The Sprint Goal provides the flexibility that requires. The Scrum Guide makes it clear:

"…the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it."

The Sprint Goal is the outcome we are after. The Product Backlog items selected to achieve it are the output. Scrum Teams should always look to maximise outcomes and minimise output. The Sprint Goal is their commitment. The selected items are their forecast.

In summary

Be clear about what you commit to, and what must instead be a forecast because of the inherent nature of complex product delivery.

Commit to goals. Commit to doing the best you can at all times. Commit to helping those around you. Commit to building products of the highest quality. Commit to the Definition of Done.

Remember that Product Backlog items taken into a Sprint are a forecast, not a commitment. Forecast longer-term plans expecting them to change and evolve as insight emerges.

Ultimately, understand and be professional about what you can and cannot commit to.

If you want to go deeper into commitments, forecasts and the rest of the Scrum framework, our Professional Scrum Master course is the place to start.