Sprint Goal Examples for Scrum Teams

What This Resource Covers

This resource gives Sprint Goal examples you can adapt with your Scrum Team. It starts with a short explanation of what a Sprint Goal is, then focuses on examples and why they work.

The examples show how a Sprint Goal can guide Sprint Planning, make the Sprint Backlog more coherent, and help the Scrum Team inspect progress during the Sprint.

What Is a Sprint Goal?

According to the Scrum Guide, the Sprint Goal is the single objective for the Sprint. It is created during Sprint Planning and added to the Sprint Backlog.

In Scrum, Sprint Goals should make sense in relation to the Product Goal. The Product Goal gives the Scrum Team a longer-term target. The Sprint Goal describes the valuable step the team is trying to take in the current Sprint toward that direction.

That matters because a Sprint can easily become a bundle of unrelated Product Backlog items. Everyone may be busy, but the work may point in different directions. A Sprint Goal gives the Scrum Team a reason for the Sprint that is larger than the item list.

The Sprint Goal also creates flexibility. If the work turns out to be different than expected, the Developers collaborate with the Product Owner to negotiate the scope of the Sprint Backlog while preserving the Sprint Goal.

Product Goal, Sprint Goal, and Sprint Backlog

A useful distinction is:

1. Product Goal: the longer-term target for the Scrum Team.
2. Sprint Goal: the valuable step this Sprint takes toward that target.
3. Selected Product Backlog items: what the Scrum Team initially believes may help achieve the Sprint Goal.
4. Plan: how the Developers intend to create a usable Increment.

The Sprint Backlog contains the Sprint Goal, the Product Backlog items selected for the Sprint, and the Developers' plan for delivering them. When the Sprint Goal is clear, the team has a better basis for adapting the plan during the Sprint.

What Makes a Sprint Goal Effective?

A useful Sprint Goal usually has these qualities:

• It expresses one objective for the Sprint.
• It explains why the Sprint is valuable.
• It connects the work to product value, learning, risk reduction, or stakeholder need.
• It supports the Product Goal or current product direction.
• It gives the Developers room to adjust the plan as they learn.
• It helps the Scrum Team inspect progress during the Daily Scrum.
• It is understandable to stakeholders without exposing every implementation detail.

A weak Sprint Goal often repeats the selected Product Backlog items: "complete login, profile editing, and export". That may describe work, but it gives little sense of purpose for the Sprint.

Sprint Goal Examples

1. Password reset

Context: A travel booking portal is moving toward more self-service account management. Today, users who forget their password often contact support because they cannot reset it on their own.

Weak version:

Build password reset.

Better Sprint Goal:

Users can reset a forgotten password without contacting support.

Why it works:

This Sprint Goal describes a useful slice of self-service account management. It is small enough for one Sprint and clear enough to inspect at the Sprint Review.

The Product Backlog items might include email verification, a reset form, token expiry, and basic error handling. The goal keeps those items connected to one user outcome: recovering access without support.

Possible inspection points:

• A user can request a reset link from the login page.
• The reset link expires after the defined time window.
• A user can set a new password and sign in again.
• Support can see fewer password-reset requests in the selected test group.

2. Restaurant table booking

Context: A small restaurant wants to let guests book tables directly from its website. Today, most bookings still happen by phone, especially for the current week.

Weak version:

Create online booking.

Better Sprint Goal:

Guests can book a table for the current week and receive confirmation.

Why it works:

The Sprint Goal defines a narrow reservation slice. Waitlists, deposits, table optimization, cancellations, and multi-location booking can come later.

The Scrum Team can focus on the minimum flow that makes the reservation real: date, time, party size, contact details, and confirmation.

Possible inspection points:

• A guest can select an available time during the current week.
• The restaurant receives the reservation details.
• The guest receives a confirmation message.
• Fully booked time slots are unavailable for selection.

3. Expense approval

Context: An internal expense management tool is moving toward faster and more transparent expense processing. Today, managers approve submitted expenses through email threads and lose track of pending requests.

Weak version:

Add manager approvals.

Better Sprint Goal:

Managers can approve or reject submitted expenses from the approval queue.

Why it works:

This is a coherent workflow slice. The Sprint can stay focused on the approval decision before the team adds advanced policies, reimbursement scheduling, accounting export, or audit reports.

The goal gives the team a clear review scenario: an employee submits an expense, the manager sees it in the queue, and the manager approves or rejects it.

Possible inspection points:

• Submitted expenses appear in the manager approval queue.
• A manager can approve an expense.
• A manager can reject an expense with a reason.
• The employee can see the updated status.

4. Delivery tracking

Context: An online store is improving post-purchase communication. Customers often contact support after purchase because they cannot see where their shipped order is.

Weak version:

Add delivery tracking.

Better Sprint Goal:

Customers can see the current delivery status for orders shipped this week.

Why it works:

The goal limits the scope to shipped orders and current delivery status. It avoids taking on every post-purchase scenario at once.

The Sprint Backlog might include carrier status integration for one carrier, a tracking view, and status labels customers can understand. The team can still learn from this slice before expanding the experience.

Possible inspection points:

• A customer can open an order shipped this week.
• The order page shows the current delivery status.
• The status updates when carrier data changes.
• Customer support can use the same status when answering questions.

5. Event registration

Context: A training company is moving toward simpler event participation through its course website. Today, event signups are managed manually, and participants need a simple way to register for one upcoming event.

Weak version:

Build event registration.

Better Sprint Goal:

Participants can register for one event and receive a calendar invite.

Why it works:

This Sprint Goal creates a complete but small user journey. Payment, waiting lists, reminders, and attendee management can come later.

The Scrum Team can focus on one event type, registration fields, confirmation, and the calendar invite. That is enough to inspect whether the flow works before adding payment, waiting lists, reminders, or attendee management.

Possible inspection points:

• A participant can submit the registration form for the selected event.
• The system records the registration.
• The participant receives a confirmation email.
• The calendar invite contains the correct time, location, or meeting link.

6. Internal knowledge base

Context: An internal employee portal is moving toward better self-service for HR information. Employees still ask HR the same policy questions because approved policy articles are hard to find.

Weak version:

Improve knowledge base search.

Better Sprint Goal:

Employees can find and open approved HR policy articles from search results.

Why it works:

The Sprint Goal narrows the search problem to approved HR policy articles. It gives the team a usable slice without promising a perfect knowledge base.

The work might include indexing approved articles, showing article titles and summaries, and filtering out drafts. The Sprint Review can use real employee questions to inspect the result.

Possible inspection points:

• Approved HR policy articles appear in search results.
• Draft or unapproved articles stay hidden.
• Employees can open the article from the result list.
• Test searches for common HR questions return relevant articles.

7. IoT device setup

Context: An IoT monitoring dashboard is moving toward faster setup of supported devices. Technicians can install sensors in the field, but connecting a new sensor to the dashboard still requires manual configuration by a specialist.

Weak version:

Support sensor setup.

Better Sprint Goal:

Technicians can connect one supported sensor type to the monitoring dashboard.

Why it works:

The goal keeps the technical work tied to a product-visible outcome. It also limits scope to one supported sensor type.

That gives the Developers room to make the integration solid before expanding to more devices. The Sprint Review can show the setup flow, the connection, and the first visible sensor reading.

Possible inspection points:

• A technician can start setup for the selected sensor type.
• The sensor can be connected without specialist configuration.
• The dashboard shows the connected sensor.
• The team can inspect setup errors from the first supported flow.

8. Subscription billing

Context: A subscription billing portal is moving toward more self-service account management. Customers still contact support before invoice dates when their billing address has changed.

Weak version:

Add billing address editing.

Better Sprint Goal:

Customers can update their billing address before the next invoice is generated.

Why it works:

This Sprint Goal is tied to a specific user task and a clear business moment: the next invoice. A full subscription-management area can come later.

The Scrum Team can focus on editing, validation, saving the address, and making sure the next invoice uses the updated information.

Possible inspection points:

• A customer can open billing details from the subscription page.
• A customer can update and save the billing address.
• Invalid address data is handled clearly.
• The next invoice uses the updated billing address.

Sprint Goal Examples That Are Too Weak

Some Sprint Goals are weak because they sound specific while giving the Scrum Team little focus.

Task list

Finish login, profile editing, invoice download, and notification settings.

This describes work selected for the Sprint. It gives little sense of why the Sprint is valuable or what coherence connects the items.

Feature name

Seller badges.

A feature name may be easy to remember, but it gives little sense of the product outcome. A better Sprint Goal would say what users should be able to understand or do because of the badge.

Vague improvement

Improve the customer experience.

This is too broad to guide decisions during the Sprint. It leaves the Scrum Team guessing which customer, which experience, and which trade-offs matter.

Output with unclear value

Complete backend refactor phase 1.

This may be important work. A stronger Sprint Goal would explain what capability, learning, risk reduction, or product value the Sprint creates.

KPI with weak Sprint direction

Increase conversion by 5%.

A metric can be useful evidence. By itself, it may give the team too little direction for the Sprint. The Sprint Goal should explain the product change or user situation the Sprint is trying to improve.

How to Use These Examples in Sprint Planning

A useful way to create a Sprint Goal is to start with the reason for the Sprint before negotiating the exact work.

Ask:

1. Which Product Goal or product direction does this Sprint support?
2. Why would this Sprint be valuable to users, customers, stakeholders, or the product?
3. Which Product Backlog items seem most relevant to that objective?
4. What flexibility do the Developers need if the work turns out differently than expected?
5. How will the Developers inspect progress toward the Sprint Goal during the Daily Scrum?
6. What would make the Sprint Review meaningful for this goal?

Then write the Sprint Goal in plain language. If it sounds like a list of tasks, step back. If it sounds like a feature name, explain the user or product outcome behind the feature. If it sounds like a distant Product Goal, make it smaller and closer to what can be achieved in one Sprint.

Related Training

Agile Way offers public and private Professional Scrum Product Owner courses. Sprint Goals are especially useful to study because they connect Scrum theory with real Sprint Planning, Product Goal, Product Backlog ordering, Developers' planning, and inspection during the Sprint.

If you are preparing for certification, you may also find How to Pass the PSM I Certification Exam and How to Pass the PSPO I Certification Exam useful.

Summary

Sprint Goal examples are useful when they show more than polished wording. A strong Sprint Goal:

1. gives the Sprint one clear objective
2. connects that objective to the Product Goal or current product direction
3. leaves room to adapt the Sprint Backlog as the Scrum Team learns

The best Sprint Goals help the Scrum Team connect the Product Goal with the work of the current Sprint. They move the conversation from "which items can we finish?" to "what valuable step are we trying to take now?".