Skip to main content
New: 9 PM Courses with hands-on exercises and certificates
Back to Glossary
DeliveryS

Sprint Goal

Definition

A sprint goal is a single, concise objective that the Scrum team commits to achieving during a sprint. It is crafted during sprint planning and provides coherence to the set of backlog items selected for the sprint. Rather than treating the sprint as a random collection of tickets, the sprint goal gives the team a unified purpose.

The Scrum Guide describes the sprint goal as a "commitment" for the Sprint Backlog, similar to how the Definition of Done is the commitment for the Increment. It is negotiable in terms of scope (the team can adjust which stories to include) but non-negotiable in terms of intent (the desired outcome should remain constant throughout the sprint).

Sprint goals serve as a decision-making filter during the sprint. When a developer finishes their current task and needs to decide what to pick up next, the sprint goal tells them which backlog item has the highest priority. When a stakeholder requests an urgent change mid-sprint, the team can evaluate it against the sprint goal: does this help achieve the goal, or does it threaten it?

Why It Matters for Product Managers

Sprint goals transform sprint planning from a capacity-filling exercise into a strategic conversation. Without a goal, planning often devolves into "how many story points can we fit?" With a goal, planning starts with "what outcome do we need this sprint?" and works backward to select the right items.

For PMs, sprint goals are also a communication tool. When your manager asks what the team is working on this sprint, you can give a crisp, one-sentence answer instead of listing 12 Jira tickets. This is especially valuable when managing multiple stakeholders who care about different aspects of the product. Connect your sprint goals to your OKRs so that every sprint visibly advances a quarterly objective.

How to Apply It

  • Write the sprint goal during sprint planning before selecting individual backlog items
  • Keep it to one sentence (two at most) that describes the outcome, not the tasks
  • Make it demo-able: you should be able to show progress toward the goal at the sprint review
  • Post the sprint goal visibly (Slack channel topic, Jira board header, team wiki)
  • Reference the sprint goal in daily standups when prioritizing work
  • Track sprint goal achievement rate over time (aim for 80%+ achievement across sprints)
  • Map each sprint goal to a quarterly OKR or product roadmap initiative

For help connecting sprint goals to broader product strategy, the guide on building a product roadmap covers how to decompose quarterly goals into sprint-sized increments.

Frequently Asked Questions

What makes a good sprint goal?+
A good sprint goal is outcome-oriented, not output-oriented. 'Complete 8 user stories' is not a sprint goal. That is a task list. 'Enable self-serve onboarding for enterprise accounts' is a sprint goal. It describes the value the sprint will deliver. Good sprint goals are testable (you can demo the outcome at the sprint review), focused (one goal, not three), and achievable within the sprint timebox. They should be written in language that a stakeholder outside the team can understand without context on specific tickets.
How does the sprint goal relate to OKRs?+
Sprint goals are the tactical bridge between quarterly OKRs and daily execution. If your quarterly Key Result is 'Increase trial-to-paid conversion from 8% to 12%', individual sprint goals might be 'Launch onboarding email sequence for trial users' (Sprint 1), 'Add in-app activation checklist' (Sprint 2), and 'Implement usage-based upgrade prompt' (Sprint 3). Each sprint goal moves the needle on the Key Result. The sprint goal answers 'what are we doing this sprint to advance our quarterly objectives?' This connection keeps sprint work strategically aligned rather than reactive.
What happens if the team cannot achieve the sprint goal?+
Missing a sprint goal is not a failure. It is a signal. The team should discuss what prevented goal achievement in the sprint retrospective. Common causes include: the goal was too ambitious for the sprint capacity, unexpected technical complexity emerged, or mid-sprint priority changes disrupted focus. The important thing is that the sprint goal remains fixed during the sprint. If circumstances change so much that the goal becomes obsolete, the Product Owner can cancel the sprint (a rare but valid option in Scrum). Never silently adjust the goal mid-sprint to make it look achieved.

Explore More PM Terms

Browse our complete glossary of 100+ product management terms.