Writing a Product Goal that a team can plan against

The 2020 edition of the Guide added the Product Goal and gave it a place at the top of the Product Backlog. Many teams still do not have one. They have a backlog, a vision slide from a kick-off and a sense of what the product is for. The goal does a different job from either, and the difference shows up when the team has to decide what to leave out.

What the Guide says

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. It lives in the Product Backlog, and the rest of the backlog emerges to define the "what" that will fulfil the goal. It is the commitment attached to the Product Backlog, the way the Sprint Goal is attached to the Sprint Backlog and the Definition of Done to the Increment. The Guide calls it the long-term objective for the Scrum Team, which must fulfil or abandon one objective before taking on the next.

The Guide also explains what a product is: a vehicle to deliver value, with a clear boundary, known stakeholders and well-defined users or customers. It could be a service, a physical product or something more abstract. So a Product Goal presumes that you can say who the product is for and where it begins and ends.

The Product Owner is accountable for developing and explicitly communicating the Product Goal. The Scrum Master serves the Product Owner by helping find techniques for effective Product Goal definition.

How it differs from nearby ideas

The vision. A vision is a statement of purpose and direction, often aspirational and without a time frame: "make it easy for every parent to find a good tutor". It guides, and cannot be finished. The Product Goal is a stage on the way: a state the product could reach in a defined period, after which the team moves to the next. See project vision and Product Goal.

The Sprint Goal. The Sprint Goal is the single objective of one Sprint, and it is created in Sprint Planning. A Product Goal spans many Sprints. A good Sprint Goal is a step toward the current Product Goal.

A roadmap or release plan. A roadmap shows how a product is likely to develop over time. The Product Goal is the destination for one stage of it. The GOV.UK Service Manual notes that roadmaps should be simple to adjust, which fits a goal that can be revised or abandoned.

A list of features. A feature list is the content of the backlog, not the goal. A goal describes the outcome the features are meant to achieve.

Four tests

These tests are ours, not the Guide's, but each follows from what it says.

1. Does it describe a state, not a to-do list? "Parents can book and pay for a first session without contacting us" is a state. "Build a booking page" is a task.
2. Can you tell when it is reached? Add a measure or an observable condition. "At least 60 percent of first bookings complete without a support call" can be checked.
3. Does it name a user or a stakeholder who benefits? A goal with no one on the receiving end is hard to prioritise against.
4. Is it one goal? The Guide asks for a single objective at a time. Two goals joined by "and" are two goals.

A fifth question is practical: could a Developer use it to decide between two backlog items? If it cannot help choose, it is too vague.

Weak and strong examples

These are illustrative.

None of these needs to be a masterpiece. It needs to be specific enough to say no to something.

A worked example

This is an illustrative case. A small company runs a tutoring marketplace. The Product Owner proposes the goal: "In the next quarter, a parent can find, book and pay for a first lesson in under three minutes, and at least half of new parents who start a search finish a booking."

The team tests it. It is a state. It has a measure. It names a user. It is one goal, although it has two parts that move together. The Developers use it in Sprint Planning. A request to add tutor reviews comes in; the Product Owner says it matters later and is not on the path to a fast first booking, so it goes down the list. A request to improve the search filters goes up, because search results are where parents drop out.

Halfway through the quarter the team learns that parents mainly drop out at payment, not search. The goal does not change, but the Sprint Goals do, and the order of the backlog follows. At the end of the quarter, the measure reads 47 percent. The Product Owner and sponsor discuss it at the Review. They can fulfil the goal in another month, or they can decide that the remaining gap is not worth the cost and abandon it for a different goal. The Guide allows either, and the decision is explicit.

Retiring a goal

The Guide's phrase "fulfil or abandon" is easy to read past. Fulfilling is the happy case. Abandoning is a legitimate decision when evidence shows the goal is no longer worth pursuing: a market has changed, a regulation has made it irrelevant, or the cost has overtaken the value. A team that cannot abandon a goal will keep investing out of habit.

Signs that a goal should be retired: the measure has stopped moving despite effort, stakeholders no longer refer to it, the backlog items below it feel unrelated to it, or the Sprint Goals are drifting away from it. A Product Owner who notices these signs should raise them at a Review, not wait for a crisis.

Common mistakes

• Writing a slogan. A goal that could apply to any product is no use for deciding between items.
• Having several at once. The Guide asks for one at a time.
• Setting it once and forgetting it. It should be visible at the top of the backlog and mentioned in Planning and Review.
• Setting a goal the team cannot influence. "Double revenue" depends on many things beyond the team. Pick a goal tied to the product's behaviour.
• Hiding the measure. If only the sponsor knows how success is judged, the team plans against a guess.

How to practise it

Write the Product Goal for something you work on in one sentence, then apply the four tests and rewrite it. In the simulator the first phase asks for a vision and a backlog before any Sprint, which is where this thinking happens.