Sprint Goal
A sprint goal is the single objective a team commits to achieving in a sprint. It is produced during Sprint Planning and owned by the team for the duration of the sprint.
A sprint without a goal is a list of tasks. A sprint with a goal is a commitment to a defined value — something meaningful that will exist or function at the end of the sprint that did not before.
What a Sprint Goal Is
The sprint goal has three properties that together make it useful.
It describes intended value, not activity. The goal says what the team is working toward, not what the team will do. “Payment validation is in place for the new checkout flow” is a sprint goal. “Implement payment validation stories” is not — it describes work, not value.
It frames the sprint backlog. Individual stories are selected because they contribute to the goal, not because they are next in the backlog. The backlog serves the goal, not the other way around. If a story does not contribute to the sprint goal, it should not be in the sprint.
It guides trade-offs. During the sprint, unexpected things happen — a dependency surfaces, a story turns out to be larger than estimated, a technical blocker appears. The sprint goal is the decision rule: what can be dropped or deferred without losing the goal? What cannot? A team without a goal has no basis for these trade-offs beyond individual judgment.
Working Software as the Verification Condition
The Agile Manifesto identifies working software as the primary measure of progress. This is not a general principle — it is the specific condition that makes a sprint goal verifiable.
A sprint goal is confirmed at Sprint Review. That confirmation requires running software: something that can be started, used, and observed. A goal that can only be demonstrated in slides or described in words is not confirmed — it is reported. The confirmation point in every sprint goal must be reachable through working software, or the goal is not well-formed.
This also means that a sprint that produces documents, analysis, or plans — but no running software — has not moved the measure of progress, regardless of the effort expended.
A Useful Template
A sprint goal can be structured as a value hypothesis:
Our focus is on [what we are putting in place] We believe it delivers [impact] to [who] This will be confirmed when [observable event in running software]
This structure forces three things: a clear delivery focus, an explicit hypothesis about value, and a confirmation point that is verifiable at Sprint Review through working software — without waiting for downstream market data.
Sprint Goal and the Sprint Backlog
The sprint goal comes first. The sprint backlog is derived from it.
During Sprint Planning, the Product Owner proposes which features and stories are most relevant given the current backlog and DVS priorities. The team and Product Owner negotiate a goal that is realistic given team capacity, then select the stories that best serve that goal.
A sprint backlog with no goal is a feature queue. The team will deliver stories, but there is no coherent value they are working toward — and no basis for evaluating at Sprint Review whether the sprint produced what the organization needed.
Evaluating the Sprint Goal
At Sprint Review, the first question is not “how many stories did we complete?” It is “did we achieve the sprint goal?”
A team can complete every story in the sprint backlog and not achieve the sprint goal — if integration fails, if the confirmation event does not occur, if the value hypothesis did not hold. Conversely, a team can achieve the sprint goal without completing every story — if the essential functionality is in place and the confirmation event is demonstrable in running software.
Stories are the means. The goal is the measure.
Connection to Higher-Level Goals
Sprint goals do not exist in isolation. They are the team-level expression of a broader delivery intent — contributing to features in the DVS backlog, which in turn contribute to the DVS-level PI goals for the current PI.
The Product Owner maintains this connection. Selecting stories that serve both the sprint goal and the team’s contribution to DVS delivery is the core of the Product Owner’s planning role.
See: Goals and Objective Setting for how sprint goals relate to PI goals and outcome goals across the delivery system.