Writing a Sprint Goal that survives a bad week

On Wednesday of week one, a story turns out to be twice the size anyone expected. The team has a list of seven items and a calendar. Without a Sprint Goal, the options are to push everything harder or to quietly drop the item nobody cares about. With one, the team has a better question to ask: which of these items still serves the goal?

What the Guide says

The Scrum Guide calls the Sprint Goal the single objective for the Sprint, and makes it the commitment attached to the Sprint Backlog. Although the goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. It also creates coherence and focus, encouraging the team to work together rather than on separate initiatives.

The goal is created during Sprint Planning and then added to the Sprint Backlog. It is the "why" part of the Sprint Backlog, alongside the set of selected items (the "what") and the plan for delivering them (the "how").

The mechanics of Sprint Planning say where the goal comes from. In Topic One, the Product Owner proposes how the product could increase its value and utility in the current Sprint, and the whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The goal must be finalised before the end of Sprint Planning.

The rule that makes it useful

If the work turns out to be different from what the Developers expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint, without affecting the Sprint Goal.

That sentence is why the goal exists. The items are a forecast and the goal is the commitment. When the forecast changes, the goal gives everyone a reason to say what to drop or swap. Without it, scope negotiation turns into an argument between people with different priorities, and the loudest wins.

Goal versus list

The commonest failure is a goal that is only a list of titles. Imagine a Sprint with these items: calendar sync, a profile page, the cancellation flow, an email template and a bug in the search results. A goal that says "Calendar sync, profile page, cancellation, email template and search fix" is an inventory. It cannot be tested except by ticking the items, and it gives no help when one of them slips, because every item is equally negotiable.

Compare:

By the end of the Sprint, a parent can find a tutor, book a lesson and cancel it if plans change.

This is a statement about the product, not about tasks. It tells the team why the calendar sync can wait (it does not serve this) and why the cancellation flow cannot (it does). The profile page might be useful or might not, and the team can discuss it using the goal as the test.

A good Sprint Goal usually has four qualities.

• Outcome, not activity. It says what will be true, not what will be done.
• Testable. At the Sprint Review someone can look at the Increment and say whether it was met.
• Singular. The Guide says "single objective". If you need "and" three times, you may have three goals.
• Connected. It moves the product toward the Product Goal, the long-term objective in the Product Backlog.

Where the goal sits among the other commitments

The Guide pairs each artifact with a commitment. For the Product Backlog it is the Product Goal. For the Sprint Backlog it is the Sprint Goal. For the Increment it is the Definition of Done. They work at three different scales:

• The Product Goal is the long-term objective the Scrum Team plans against.
• The Sprint Goal is the objective of this Sprint.
• The Definition of Done is the quality bar applied to each item.

If you cannot say how the Sprint Goal helps the Product Goal, one of them is probably wrong.

A worked example

Here is an invented but realistic case. A team is building a booking service for a tutoring collective. The Product Goal is for parents to arrange and pay for lessons online. The Product Owner enters Sprint Planning with the top of the backlog: find a tutor, view availability, book a slot, pay, cancel, receive reminders, and a long tail of admin tools.

Topic One, why is this Sprint valuable? The Product Owner argues for something a real parent could use end to end, even in a crude form, because the Sponsor is expecting a demonstration. The team proposes: "A parent can find a tutor and book and pay for a lesson."

Topic Two, what can be done? The Developers select find, availability, book and pay. They leave out cancellation and reminders. In week one they discover that the payment provider needs a test account that takes three days to approve. They tell the Product Owner on the day it happens, and agree to build the payment step against a stub and swap in the real one if the approval comes through. The goal is intact: a parent can complete a booking. The scope of one item has changed.

At the Sprint Review the team shows booking and a payment flow that works against the stub, says so plainly, and the stakeholders can judge it. That is a real outcome of using a goal: honesty about what was and was not achieved.

What to do when the goal itself is wrong

Sometimes new information makes the goal pointless. A competitor releases the feature, the budget changes, or a legal ruling moves the priorities. The Guide says a Sprint could be cancelled if the Sprint Goal becomes obsolete, and only the Product Owner has the authority to cancel. That is a last resort. In most cases the better move is to complete a coherent Sprint and change direction at the next Sprint Planning.

Common mistakes

• No goal. Many teams skip it because the backlog feels like enough. The cost shows up later, when scope changes and nobody has a reason to choose.
• A goal written afterwards. If it is assembled from the items after they were selected, it will describe what the team chose, not why.
• A goal that is the whole Sprint Backlog. "Deliver the Sprint" is not an objective.
• A goal the Product Owner writes alone. The Guide has the whole Scrum Team define it, because the Developers are the ones committing to it.
• Treating the goal as a promise to deliver every item. The commitment is to the objective. The items can change while it stays.
• A goal nobody mentions again. If it is not referred to at the Daily Scrum, it is decoration. The Daily Scrum exists to inspect progress toward the Sprint Goal.

The Agile Manifesto asks that working software be the primary measure of progress. A good Sprint Goal turns that into something specific enough to check.

How to practise it

A Sprint Goal is only as useful as the next argument it settles. In the simulator, planning ends with committed stories and a Sprint Goal, and the later steps put pressure on both: a mid-sprint change request, a blocker, and a review where the work is accepted or rejected.