What Scrum Originally Said
The Scrum Guide has shifted on this question over its lifetime. Early versions described the sprint commitment as a quantity of work — items selected, committed to, and delivered. The 2011 revision replaced "commit" with "forecast" to soften the contractual feel. The 2020 revision elevated the Sprint Goal as the central commitment, with the selected backlog items being a means to that goal rather than the commitment itself.1
The current Scrum Guide is unambiguous: the team commits to the sprint goal. The selected items are a forecast, not a contract. But most teams in practice still operate under the older model — committing to a list, treating scope as fixed, measuring "success" by items completed.
The Case for Sprint Goals
- Outcome-focus. The sprint goal answers "what are we trying to accomplish?" — a question scope-commitment can't answer at all.
- Adaptive scope. If a story turns out to be the wrong shape, the team can swap it for something that better serves the goal without breaking commitment.
- Coherent stakeholder conversations. Reviewers can ask "did we move the goal?" instead of "did you complete the list?"
- Better refinement. A backlog that has to coalesce into a goal forces better prioritization than a backlog that just gets pulled off the top.
How Sprint Goals Go Wrong
- Goals too vague. "Make progress on checkout" is not a goal; it's a topic. Teams that don't sharpen the goal end up with the worst of both worlds.
- Goals too rigid. A sprint goal that's truly singular ("ship feature X") can also become a contract — and a missed feature X means a "failed" sprint regardless of what was learned.
- Two-goal sprints. Trying to serve two unrelated goals in one sprint dilutes focus. If the team has two priorities, they aren't really priorities.
- Stakeholders ignore the goal. If leadership keeps asking about ticket counts, the team can have a goal in name only.
The Case for Backlog Commitment
- Concrete and verifiable. "We committed to these eight items, we delivered seven" is empirical.
- Familiar to stakeholders. Most non-agile leaders understand item commitments more readily than outcome commitments.
- Forces refinement. Items have to be small and well-understood to be committed to.
- Easier with maintenance work. When the sprint is a mix of small unrelated items (bug fixes, minor improvements), backlog commitment is more honest than a forced goal.
How Backlog Commitment Goes Wrong
- Optimization for ticket completion. Teams cut corners to hit item commitment, even when the work is poor.
- Drift to feature-factory mode. Sprints become a stream of completed items with no thread tying them together.
- The goal that emerges is "complete the list." No deeper purpose, no integration, no story to tell at review.
- Loss of meaning. Teams that commit only to lists struggle to answer why they're doing what they're doing.
The Synthesis
The honest position: commit to a sprint goal as the primary anchor; forecast the items that should accomplish it. The forecast is mutable; the goal is what the team is trying to achieve. If a story turns out wrong, the team can replace it with one that serves the goal better. If the goal turns out unreachable, that itself is information — and the team replans rather than crashing into sprint-end.
For maintenance-heavy sprints where there's no obvious unifying outcome, an honest framing is to acknowledge that explicitly: "this sprint is a maintenance batch; our goal is to clear the bug backlog by 50%." That's still a goal — just one shaped by the work's nature.
The Deeper Question
This debate is really about whether the team thinks of itself as doing work or as producing outcomes. The doing-work mental model treats the backlog as a queue to be processed. The producing-outcomes mental model treats the backlog as raw material for whatever the team is trying to achieve. The first mental model is administratively easier; the second produces better products.
Coaching Tips
Write the goal as a sentence.
"Reduce checkout drop-off in step three" is a goal. "Work on checkout" is a topic. The sentence test is the discipline.
Open the review with the goal, not the burndown.
"Here's what we were trying to achieve, here's what the evidence says now." The format reshapes everything that follows.
Allow goal-aligned scope swaps.
If a story turns out wrong mid-sprint, replacing it with one that serves the goal is honest. Defending the original list is theatre.
Beware the two-goal sprint.
Two goals usually means no goal. Pick one, push the other to next sprint.
Frame maintenance sprints honestly.
"Clear the bug backlog by 50%" is a legitimate sprint goal. Forced poetic goals on maintenance work feel fake.
Track goal-met rate, not item-completion rate.
"Did we move what we set out to move?" is the right question. Item percentage is a side metric at best.
Summary
The sprint-goal debate is really about whether agile teams operate as queues processing items or as missions delivering outcomes. The Scrum Guide has come down firmly on the side of outcomes; most teams in practice still operate as queues. The right move is to commit to a goal, forecast the items that should advance it, and let the forecast flex without letting the goal slip. It is the discipline that turns a sprint from a batch of work into a small bet the team is running.
- Schwaber, Ken and Jeff Sutherland. The Scrum Guide. 2020.
- Pichler, Roman. Agile Product Management with Scrum. Addison-Wesley, 2010.
- Cagan, Marty. Inspired. 2nd Edition, Wiley, 2018.