How to set a sprint goal (with examples)
A sprint goal is one sentence that says why the sprint matters. Here is what makes a strong goal, why it comes before scope, and side-by-side examples of weak and strong goals.
A sprint goal is a single sentence that says why the sprint is worth doing. It is the one outcome the team commits to — the thing that is meaningfully true when the sprint ends. Everything the team selects should serve it, and when the sprint gets tight, the goal is what tells you which work to protect and which to drop.
Most teams treat the goal as a summary of the tickets they picked. That is backwards, and it is why so many goals are useless.
The goal comes before the scope
Set the goal first, then choose work that serves it. A goal reverse-engineered from a pile of already-selected tickets (“deliver items 4, 7, and 12”) is not a goal — it is a table of contents. It cannot help you make a decision, because it has no opinion about what matters.
The order is the whole point. When you agree the outcome before the scope, selection becomes a series of easy questions: does this item move us toward the goal? If yes, pull it. If no, it had better be a very good reason — a security fix, a hard dependency — or it waits. When you pick scope first, every item feels equally load-bearing, and there is nothing to cut when Thursday goes sideways.
What a strong goal does
A goal earns its place when it can do three jobs:
- It names an outcome, not a task list. “Users can reset their own password without contacting support” tells you what is different in the world. “Complete the password-reset epic” tells you which Jira board to look at.
- It makes trade-offs for you. The real test of a goal is the last day of the sprint, when not everything will land. A good goal tells you instantly what to protect. If the goal is “let users reset their password”, you ship the reset flow and let the nice-to-have email restyling slip. If the goal is “finish the tickets”, you have no basis to choose, so everything slips a little and nothing ships clean.
- The team can say it from memory. A goal nobody can recite is a goal nobody is steering by. If the team has to open the planning doc to remember why they are here, the goal is too long or too vague.
Weak goals vs strong goals
The gap between a weak goal and a strong one is almost always the gap between naming activity and naming an outcome.
| Weak goal | Why it fails | Strong goal |
|---|---|---|
| ”Work on the checkout redesign.” | Names an area, not a result. No finish line. | ”A returning customer can complete checkout in under a minute on mobile." |
| "Close 40 story points of backlog.” | An output measure the goal should serve, not be. | ”Cut the top three reasons customers contact support about billing." |
| "Improve performance and fix bugs.” | Two goals, no priority, no way to trade off. | ”The dashboard loads in under two seconds for accounts with 10,000+ records." |
| "Finish the reporting feature.” | ’Finish’ hides the scope; whose definition of done? | ”Managers can export a weekly team report as a PDF without help from us.” |
Notice the strong goals share a shape: a specific user or system, doing a specific thing, to a specific standard. You could demo each one and the room would agree, without argument, whether it was met.
One goal, not several
Aim for a single goal. One goal is what makes trade-offs possible — with two competing objectives, there is no principle for which to defend when time runs out, and you are back to everything-slips-a-little.
If the work genuinely refuses to fit under one goal, treat that as a signal rather than a problem to paper over. Usually it means the sprint is carrying too much, or that two streams of work have been merged into one sprint that would be clearer as two. Occasionally a small amount of unrelated keep-the-lights-on work rides alongside the goal — that is fine, as long as everyone knows it is the ballast, not the mission.
Who owns the goal
The product owner brings the intent — the business reason this sprint matters more than the alternatives. The whole team shapes that intent into a goal it can actually commit to, which means the developers have to believe it is achievable with the capacity available. A goal the team does not believe in is a wish with a deadline.
Once you have a goal worth committing to, the rest of planning gets easier: the agenda uses it as the test for selecting work, and the daily scrum uses it as the thing progress is measured against. The goal set on Monday is what the team steers by all sprint.
Frequently asked questions
What is a sprint goal?
A sprint goal is a single sentence that states why the sprint is worth doing — the one outcome the team is committing to. It is set during sprint planning, before scope, and it gives the team a shared objective that the selected backlog items serve. It is the reason the sprint exists, not a list of the tickets in it.
What makes a good sprint goal?
A good sprint goal names an outcome, not a task list; it is specific enough to tell you what to drop when the sprint gets tight; and the whole team can state it from memory. If your goal is just “finish these tickets”, it cannot help you make trade-offs — which is the one job a goal has.
Who sets the sprint goal?
The product owner brings the intent — the business reason this sprint matters — and the whole team shapes it into a goal they can commit to during planning. It is a collaboration, not a directive. The developers have to believe the goal is achievable with the capacity available, or it is just a wish.
Can a sprint have more than one goal?
Aim for one. A single goal is what lets the team make trade-offs under pressure — with two competing goals, there is no principle for which to protect when time runs short. If the work genuinely splits in two, that is often a sign the sprint is trying to do too much, or that two teams’ work has been merged into one sprint.