Product Goal and Sprint Goal Explained (With Examples)

Many Scrum Teams work hard every Sprint but struggle to explain why their work matters. Often the missing piece is a clear goal. Scrum has two: the Product Goal, which gives the product a long-term direction, and the Sprint Goal, which explains why each Sprint is valuable. This guide explains both according to the Scrum Guide, shows how they fit together, and gives practical steps and real-world style examples for writing goals that actually guide decisions.

Key takeaways

• The Product Goal is the long-term objective for the Scrum Team and the commitment for the Product Backlog.
• The Sprint Goal is the single objective for a Sprint and the commitment for the Sprint Backlog.
• The team works toward one Product Goal at a time, and each Sprint Goal should be a step toward it.
• A good goal describes an outcome and a reason, not a list of tasks.
• The Sprint Goal stays fixed during the Sprint, while the exact work to reach it can change.

Why goals matter in Scrum

The 2020 edition of the Scrum Guide introduced a commitment for each of Scrum's three artifacts: the Product Goal for the Product Backlog, the Sprint Goal for the Sprint Backlog and the Definition of Done for the Increment. According to the guide, these commitments exist to improve transparency and focus, and give the team something against which progress can be measured.

Without goals, a Product Backlog is just a list, and a Sprint is just a batch of tasks. With them, every item has a reason, every decision has a reference point, and stakeholders can see where the product is heading. Our article on Scrum artifacts explains all three commitments.

What is a Product Goal?

According to the Scrum Guide, the Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. It is in the Product Backlog, and the rest of the Product Backlog emerges to define what will fulfil the Product Goal. The guide calls it the long-term objective for the Scrum Team.

Two rules matter most:

• One at a time. The Scrum Team must fulfil or abandon one Product Goal before taking on the next.
• The Product Owner is accountable for it. Developing and explicitly communicating the Product Goal is part of the Product Owner's accountability for the Product Backlog.

The Scrum Guide also describes what a "product" is in this sense: a vehicle to deliver value, with a clear boundary, known stakeholders and well-defined users or customers. A product could be a service, a physical product or something more abstract.

What is a Sprint Goal?

The Scrum Guide describes the Sprint Goal as the single objective for the Sprint. It is created during Sprint Planning and added to the Sprint Backlog. Although it is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.

The guide explains that the Sprint Goal creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different from what they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint, without affecting the Sprint Goal.

Product Goal vs Sprint Goal

	Product Goal	Sprint Goal
Commitment for	Product Backlog	Sprint Backlog
Time horizon	Long term, often several Sprints or more	One Sprint (one month or less)
Who is accountable	Product Owner	A commitment by the Developers, defined by the whole Scrum Team
When it is set	When needed; one at a time	In Sprint Planning, every Sprint
Purpose	Gives the product direction	Explains why this Sprint is valuable
When it changes	When fulfilled or abandoned	Not during the Sprint; a Sprint may be cancelled if it becomes obsolete

How the goals fit together

Think of the Product Goal as the destination and each Sprint Goal as the next leg of the journey. Every Sprint Goal should move the product noticeably closer to the Product Goal. At each Sprint Review, the team and stakeholders discuss progress toward the Product Goal and decide what to do next, which shapes the following Sprint Goal.

Many organisations also use a product vision: a broader, longer-lasting statement of why the product exists. A vision is not part of the Scrum Guide, but it can be useful context. In that case, the vision describes the lasting purpose, the Product Goal is the current major objective on the way there, and Sprint Goals are the steps toward that objective.

How to write a good Product Goal

Step 1: Start with customers and their problem

A Product Goal should describe a better future for the people the product serves. Begin with what you know about customers: what they struggle with, what they need and what they value.

Step 2: Describe an outcome, not a feature list

"Build a mobile app with ten features" is a plan. "Customers can manage their account entirely on their phone" is an outcome. Outcomes leave room for the team to find the best way there.

Step 3: Make progress visible

The Scrum Guide describes commitments as something against which progress can be measured. A Product Goal does not need a precise number, but the team and stakeholders should be able to tell whether they are getting closer.

Step 4: Choose a realistic horizon

A Product Goal should be big enough to guide several Sprints, but not so distant that nobody can relate to it. If it would take years, it may be closer to a vision than a goal.

Step 5: Share it and keep it visible

Put the Product Goal at the top of the Product Backlog, refer to it in Sprint Planning and the Sprint Review, and make sure stakeholders know it.

Signs of a good Product Goal

• It focuses on value for customers or the organisation.
• Anyone on the team can explain it in their own words.
• It helps decide which backlog items belong at the top.
• Progress toward it can be seen and discussed.
• It is one clear objective, not several combined.

Product Goal examples

These examples are illustrations, written for this guide:

Product	Weak	Stronger
Online banking app	Release version 3.0	New customers can open an account and make their first payment in one sitting, without visiting a branch
Internal HR system	Add more features for managers	Managers can approve leave and expenses in under a minute, from any device
Online course platform	Improve the platform	Learners can complete a full course on a mobile phone without needing a computer

How to write a good Sprint Goal

According to the Scrum Guide, the Sprint Goal is defined in Sprint Planning. The Product Owner proposes how the product could increase its value and usefulness in the current Sprint, and the whole Scrum Team collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalised before the end of Sprint Planning.

Step 1: Start from the Product Goal

Ask what the most valuable next step toward the Product Goal would be, given what the team learned last Sprint.

Step 2: Agree the why before the what

Settle on the objective first, then select the Product Backlog items that serve it. Choosing items first and inventing a goal afterwards usually produces a weak Sprint Goal.

Step 3: Keep it to one objective

The Sprint Goal is a single objective. If the team is tempted to list three goals, it may need to choose, or the work may belong to more than one Sprint.

Step 4: Make it understandable to stakeholders

A stakeholder should be able to read the Sprint Goal and understand why the Sprint matters to them.

Step 5: Leave room for flexibility

A good Sprint Goal allows the Developers to adjust the exact work as they learn, while still achieving the objective.

Common Sprint Goal templates

The Scrum Guide does not prescribe a format. Some teams find a simple template helpful, such as:

• "In this Sprint we will [objective] so that [benefit]."
• "Our focus this Sprint is [objective]. We will know we have achieved it when [observable result]."

Sprint Goal examples

These examples are illustrations, written for this guide:

Weak	Stronger
Complete items 21, 24, 25 and 30	New customers can sign up and verify their identity without contacting support
Work on the payment module	Customers can pay with a saved card in two taps, so repeat purchases are faster
Fix bugs	Reduce failed checkouts by fixing the three errors customers report most often
Do research	Find out whether customers would use in-app chat, so we can decide whether to build it
Frontend and backend tasks for the dashboard	Managers can see this week's team availability on one screen

Notice that the stronger versions explain who benefits and why, and leave the team room to decide exactly how to get there. A Sprint Goal can also be about learning, as in the fourth example.

Using the Sprint Goal during the Sprint

• At the Daily Scrum: the Scrum Guide says the purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed.
• When something unexpected happens: the team can ask, "Does this help us reach the Sprint Goal?"
• When the work turns out different: the Developers collaborate with the Product Owner to renegotiate scope, without affecting the Sprint Goal.
• When new requests arrive: requests that would endanger the Sprint Goal are directed to the Product Owner for the Product Backlog, rather than added to the current Sprint.
• If the Sprint Goal becomes obsolete: the Product Owner may cancel the Sprint. This should be rare.

For more on the events where goals are set and inspected, see the five Scrum events explained.

What if the team does not meet the Sprint Goal?

Missing a Sprint Goal is not a failure of Scrum; it is information. Complex work is uncertain, and sometimes the team learns that the goal was harder than expected. What matters is inspecting why at the Sprint Review and the Sprint Retrospective. Was the goal too big? Did unexpected work arrive? Was the goal unclear? The answers help the team set better goals next time. If Sprint Goals are missed regularly, it usually points to planning too much, frequent interruptions or goals that are really lists of tasks.

Why teams struggle to set a Sprint Goal

• The backlog is full of unrelated items. Ordering the Product Backlog around the Product Goal makes coherent Sprint Goals much easier.
• The team works on several products. This makes a single objective hard. It may be a sign that the team's setup needs to change.
• Most work is urgent support. For teams dominated by unplanned work, a flow-based approach may fit better; see Kanban vs Scrum.
• The goal is set after the items are chosen. Agree the objective first.
• Nobody refers to the goal after Planning. Keep it visible and use it at every Daily Scrum.

When to change or abandon a Product Goal

The Scrum Guide says the team must fulfil or abandon one Product Goal before taking on the next. A Product Goal is fulfilled when the future state it describes has been reached. It may be abandoned when the team learns that it is no longer valuable: for example, customer needs change, the market shifts, or evidence shows the goal was based on a wrong assumption. Abandoning a goal on evidence is a healthy use of empiricism, not a failure. The Product Owner is accountable for making that call and communicating it clearly.

Goals when several teams share a product

When several Scrum Teams work on the same product, the Scrum Guide says they share the same Product Goal, Product Backlog and Product Owner. Each team still sets its own Sprint Goal, but those Sprint Goals should fit together and move the shared Product Goal forward. Coordinating them during Sprint Planning helps avoid teams pulling in different directions.

Product Goals and OKRs

Objectives and Key Results (OKRs) are not part of Scrum, but many organisations use them to set direction. Some connect the two: an organisational objective informs the Product Goal, and key results help show progress toward it. This can work well, as long as the Product Goal remains one clear objective owned by the Product Owner, and Sprint Goals keep their focus on value rather than on reporting.

A worked example: from Product Goal to Sprint Goals

As an illustration, imagine an online banking team with the Product Goal: "New customers can open an account and make their first payment in one sitting, without visiting a branch." Over three Sprints, its Sprint Goals might look like this:

1. Sprint 1: "New customers can enter their details and upload identity documents online, so we can test where people drop out."
2. Sprint 2: "Identity checks are completed automatically for most customers, so they no longer wait for a manual review."
3. Sprint 3: "Newly verified customers can add a payee and make their first payment straight after sign-up."

Each Sprint Goal is a clear step toward the Product Goal. At each Sprint Review, the team and stakeholders look at the results, such as how many customers finished sign-up, and adjust the next Sprint Goal if they learn something unexpected.

Sprint Goals for different kinds of Sprints

Not every Sprint is about new features. The Sprint Goal should reflect what matters most right now:

• A feature Sprint: "Customers can track their order in real time, so they stop calling support to ask where it is."
• A learning Sprint: "Find out whether small businesses would pay for invoicing, so we can decide whether to build it."
• A quality Sprint: "Make checkout reliable enough to handle our peak season, so no customer loses a basket due to errors."

Whatever the focus, the Scrum Guide says quality should not decrease during the Sprint, and every Sprint should still produce a usable Increment that meets the Definition of Done.

Keeping goals visible

A goal only helps if people see it. Many teams put the Product Goal at the top of the Product Backlog and the Sprint Goal at the top of their Sprint board, read the Sprint Goal aloud at the start of each Daily Scrum, and open the Sprint Review by restating both goals. These small habits keep decisions anchored to the reason for the work.

Common mistakes with goals

• Goals that are really task lists. A list of items gives no guidance when plans change.
• Several Product Goals at once. Scrum works toward one Product Goal at a time.
• A Product Goal that never changes. If it is never fulfilled or abandoned, it may be too vague to guide decisions.
• Sprint Goals unrelated to the Product Goal. Each Sprint should move the product toward its objective.
• Treating the Sprint Goal as a promise to stakeholders at any cost. Quality should not decrease to meet it.

Learn more

Setting goals is one of the most practical Product Owner skills. Our complete Product Owner guide covers the full role, how to manage a Product Backlog explains how goals shape backlog order, and what does a Product Owner do? shows the role day to day. Product Owner Plus (Associate) covers product vision, backlog management and stakeholder alignment; the exam is taken online on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years.