The home-robot company's Product Owner writes: 'By the end of Q3, the companion app reliably reconnects to the robot after any home Wi-Fi drop, with no customer-visible setup step.' The Scrum Team then pulls Product Backlog items over several Sprints that all move toward that statement. What is that statement functioning as?
Select an answer to reveal the explanation.
Short Explanation
That statement is the destination on the map, not one leg of the trip — that's what a Product Goal is. It gives the whole Product Backlog something to aim at, so the team can look at any item and ask whether it moves the product toward that reconnection goal or not.
Full Explanation
The Product Goal is one of the Scrum Guide's three commitments — it belongs to the Product Backlog and describes a future state of the product that the Scrum Team plans toward, usually spanning multiple Sprints rather than one. In this example, reliable Wi-Fi reconnection isn't a single Sprint's worth of work; it's a horizon the Product Owner has set so that Product Backlog items — a reconnection-retry algorithm, a firmware watchdog timer, an app-side status indicator — can all be evaluated against whether they serve it. That's different from a Sprint Goal, which is the commitment for a single Sprint's Sprint Backlog and is set by the Developers together with the Product Owner during Sprint Planning; it's also different from the Definition of Done, which is a quality bar for calling any increment releasable, not a target for the product itself. Confusing the Product Goal with a stakeholder request also misses the point: a Product Goal is the Product Owner's articulation of direction, distilled from many inputs, not a single ask waiting in a queue. A practical check: can the Scrum Team look at the next few Product Backlog items and explain, in one sentence each, how they move the product toward the Wi-Fi statement?