Scrum, day 10: a Product Goal that guides decisions

Today's objective: describe a future state of a product that can guide several Sprints, then use it to explain a choice between competing improvements.

Read alongside: the Product Goal section of the Scrum Guide, then revisit the product discussion in Scrum: A Pocket Guide, fourth edition, §2.5, “Playing the game.” Allow roughly five minutes for this companion, plus the assigned reading.

Give a capable team a useful direction

The fictional ShiftSwap team now has a clearer approval flow and is reducing the dependencies that delayed its work. The Product Backlog is growing too. It includes an approval reminder, a reporting dashboard, support for more cafés, a new visual theme, and a way to explain why a swap was declined.

Each request can be defended. The team could spend several Sprints completing them in the order they arrive and still struggle to explain what has improved for employees or managers.

In day 07, we used this Product Goal:

Employees at the first two cafés can arrange eligible swaps and tell when they are final without a manager reconstructing conversations.

Today, examine whether that statement gives the team enough direction to choose its next work and recognize meaningful progress.

Name the future state you want to reach

The goal identifies users, a bounded setting, and a useful change in their experience. It leaves room for the team to discover which capabilities will produce that result. The answer might include better status messages, different approval behavior, or an easier way to find a decline explanation.

Compare it with “build notifications, reports, and a new theme.” That is a proposed set of outputs. Completing them would establish that the team shipped those features; it would not establish that employees can reliably arrange swaps.

“Make scheduling better” has the opposite problem. It leaves so much open that people could attach almost any request to it. ShiftSwap's current goal is narrower: it concerns eligible exchanges at the first two cafés and the effort needed to understand their status.

The Scrum.org Product Goal reference describes the goal as a future state that gives context to the Product Backlog. Its usefulness can be tested in ordinary decisions: does it help people explain why a particular improvement deserves attention now?

Clarify how you will inspect progress

The team still needs to discuss what the goal means in practice. What makes a swap eligible? What does the manager currently reconstruct? What would count as employees understanding a final arrangement?

Elena works with the team, employees, and managers to describe observable evidence. They will look at completed requests, cases where someone asks the manager to interpret the state, and requests abandoned because the next step is unclear. They will also check that a seemingly successful swap respects the café's approval rules.

Suppose, for this invented example, they begin with ten recent eligible requests that involved manager help in six cases. They choose to inspect the next twenty completed eligible requests across the two cafés and discuss every case that still needs interpretation. They set a review date even if the product has not accumulated twenty requests by then.

That is an evaluation plan, not a scientific guarantee or a Scrum requirement. A small sample can expose recurring problems, but it cannot prove that every future user will succeed. Counting only completed requests could also hide people who abandon the process, so the team records those experiences separately.

Scrum.org's guidance on formulating a Product Goal recommends making progress measurable. The particular measures, thresholds, and observation window depend on the product. They should make the intended result clearer without rewarding behavior that defeats it.

Use the goal to order real alternatives

The Product Owner considers the current requests against that direction:

The goal does not mechanically produce a backlog order. The team still considers risk, effort, dependencies, and new information. It does make the reasoning easier to examine. A theme change addressing a serious readability problem would deserve a different discussion from a purely decorative change.

Connect a Sprint without shrinking the longer-term goal

The Product Goal may require several Sprints. A Sprint Goal provides a nearer purpose, such as enabling employees at the second café to understand pending and final states during a supervisor handover.

That Sprint can produce a usable improvement toward the broader direction. Its work does not need to solve every remaining problem at both cafés. The distinction helps the team select a coherent next step while keeping the larger result visible.

The Product Owner is accountable for developing and communicating the Product Goal. Collaboration with the team and stakeholders improves the information behind it. The goal then helps the Developers understand why particular work matters, while they retain responsibility for planning how to create the Increment.

Know when the direction should change

A Product Goal should be stable enough to guide choices and open to evidence that challenges its value. Suppose the pilots reveal that employees rarely need to exchange shifts at all; their larger problem is managers changing the schedule without warning. That would justify investigating whether the current direction still deserves investment.

The Scrum Guide requires the team to fulfill or abandon its current Product Goal before taking on the next. Making that choice explicit helps prevent several competing goals from quietly accumulating behind one backlog.

Abandoning a goal needs an explanation of what was learned and what that means for the product. Achieving a goal also needs evidence. Shipping the last feature on an old list should not automatically settle either question.

Test your own goal against a choice

Write one sentence describing a future product state: who should be able to do what, in which setting, with what useful difference? Name one observation that would indicate progress and one that could make you question the direction.

Now place two plausible backlog items beside the sentence. Explain which you would consider first and why. If the goal supports both equally regardless of their purpose, make it more specific. If it prescribes every implementation detail, leave more room to learn how to reach the result.

Reflection: could someone use your goal to decline an attractive request respectfully? A useful direction helps explain both the work you pursue and the work you defer.

In the next companion, we examine Product Owner accountability in more detail and distinguish making product decisions from doing every task personally.