What Are We Really Committing to in Scrum?

"The Sprint Backlog is a forecast by the Development Team."

In 2011, the language used in the Scrum Guide to describe a Sprint Backlog was significantly revised. Up until that point, the work selected by a team for actioning in a Sprint was referred to as a commitment. From then onwards, it would be acknowledged instead as being a forecast. That is still the language used in the Guide today, even though subsequent versions have codified "commitment" to be a Scrum value, and teams are expected to engage in commitment-based planning.

Since the term "forecast" is somewhat weaker than "commitment,"though, we can perhaps be forgiven for wondering what exactly is going on. Are team members expected to commit to anything of substance these days? If so, what ought it to be?

Well, the Scrum Guide also says that "people personally commit to achieving the goals of the Scrum Team." There's our clue. The Sprint Backlog is, in truth, a forecast of the work needed to achieve the most essential goal in the Scrum Framework -- the Sprint Goal -- and that's what they should commit to. A Product Backlog, meanwhile, can be seen as a longer-term forecast, matured through continuous refinement, about the work that is likely to be delivered in upcoming Sprints.

Remember that, in Scrum, the Sprint Goal does not change at any point during the iteration. If it ceases to be viable, then the Sprint ought to be cancelled and a new one planned immediately. That's how critical the Sprint Goal is. It's an immutable point of reference against which other things should evolve and emerge in light of discovery. It is the Sprint Goal, and not the Sprint Backlog, which represents the more artful team commitment. In essence, measuring how much work is left in the Sprint Backlog ought to be nothing more than an exercise in forecasting goal actualization.

The implications of this can send many agilists into conniptions. A team should clearly make a good forecast in order to have transparency over the work remaining in a Sprint. That forecast could turn out to be wrong, however, perhaps with no story being completed at all by the end of the timebox, and yet the Sprint Goal could still be met by a competent team with a useful increment delivered. Valuable work will have been performed which meets the Definition of Done and the Sprint Goal, and which is fit for potential release. That work will have been "done" and invested in the increment. The purpose of Sprint Backlog items is to provide transparency over work in progress, but their actual completion is, strictly speaking, quite immaterial.

Forecast 

Forecast is Pattern of the Month at agilepatterns.org

Intent: Predict completion time based on the estimated size of a backlog and a known velocity

Proverbs:

• If we are to understand the future we must look at the past.
• Forewarned is forearmed.

Motivation: Agile teams must be prepared to respond to change, and cannot always make a delivery commitment. Yet even in conditions of extreme uncertainty, it is valuable to have a provisional timeline based on existing data and clear assumptions.

Structure: A team has an ordered backlog of items to deliver. The team only allows a limited number of items to be work in progress at any one time. The velocity or throughput can be calculated by inspection and a forecast made regarding the likely time of delivery for items remaining in the backlog. Metrics are captured iteratively on a timeboxed basis. The method used to derive these metrics and make such forecasts can be adapted by the team in order to improve their usefulness.

Applicability: Forecasting is used in most agile methods in order to determine the likely deliverables by the end of a given timebox.

Consequences: Forecasts can be mistaken for commitments and it is important to qualify expectations accordingly. The accuracy and value of forecasts diminishes the further into the future they extend.

Implementation: Scrum development teams generally limit their forecasts to end-of-Sprint deliverables. The Sprint Backlog and Sprint Goal effectively represent their forecast, and will depend on estimates. Kanban forecasting does not necessarily use estimation at all. For small and repeatable changes, forecasts based on backlog position and throughput are possible.

Further reading:

Scrum Myth: The Sprint Backlog is a Commitment 

Commitment Considered Harmful

Scrum: The Obsession With Commitment Matching Velocity