Setting and Using a Product Goal: Lessons from a Government Digital Team

This account describes a composite of real situations, with identifying details changed.

The team was a digital services unit within a provincial government, charged with building an online portal for a benefits administration programme. Six developers, one Product Owner, a Scrum Master. They had been running Scrum for eight months. The team was competent and the Scrum ceremonies were running well. But every Sprint Review produced a concern that the Scrum Master could not quite articulate: the work being completed each Sprint felt disconnected. User research in Sprint 4 had led to a redesign of the authentication flow. An executive's suggestion in Sprint 6 had added a new notification module. A stakeholder presentation in Sprint 9 had pivoted the team toward a reporting dashboard. The Product Backlog was long and well-ordered, but no one could explain concisely what the product was for — right now, in this phase, with these resources.

The Problem the Product Goal Solved

The Scrum Guide states: the Product Goal is the long-term objective for the Scrum Team, and the current Product Goal must be achieved or abandoned before the team can take on another. That is exactly what the team was missing. Without a Product Goal, every request from every stakeholder was evaluated against the question 'is this a good idea?' rather than 'does this serve our current goal?' Both are valid questions, but without a Product Goal, the first has no filter. The Product Owner was accepting reasonable-sounding work from reasonable people at reasonable times, and the product was drifting.

Introducing the Product Goal and What Changed

• The Product Owner, working with the Scrum Master and the programme director, drafted a Product Goal for the current phase: "Enable benefits applicants to complete and submit an eligibility determination online, without requiring a phone call or in-person visit, by the end of Q2 2022." This was specific, outcome-oriented, and time-bounded.

• The Product Goal was added as the commitment attached to the Product Backlog. Every item in the backlog was reviewed against the question: does this serve the Product Goal? Items that did not serve the current goal were moved to a separate "future consideration" section.

• When the executive with the notification module request returned, the Product Owner was able to have a different conversation: "That's a valuable feature. It is not in scope for our current Product Goal, which is focused on eligibility submission. I can put it in the backlog for the next phase and flag it for prioritisation then." The executive accepted this. He had not been told no; he had been told not yet, with a reason.

• The team began measuring Sprint success not just by whether items were completed, but by whether the Sprint Goal — which now explicitly supported the Product Goal — had been achieved.

• By the end of Q2, the eligibility submission feature was live. The team delivered on its Product Goal for the first time. The following quarter, the notification module was the first item in the new Product Goal for phase two.

The Lessons

1. A Product Goal is not a project plan. It is a medium-term objective that gives the team a direction and a filter. It does not specify how the goal will be achieved — that is what the Sprint Goals and Sprint Backlog are for.

2. The Product Goal enables the Product Owner to say not yet. Without a Product Goal, every stakeholder request is evaluated on its own merits, and good ideas crowd out the goal. With a Product Goal, the Product Owner has an articulable reason to defer work that does not serve the current objective.

3. The Scrum artifacts have commitments for a reason. The Product Backlog's commitment is the Product Goal; the Sprint Backlog's commitment is the Sprint Goal; the Increment's commitment is the Definition of Done. These commitments are what make the artifacts planning tools rather than lists.

XNM supports public-sector and capital-project organisations in building effective Scrum and agile delivery practices, including Product Goal setting and Product Backlog management. Reach out to XNM's program & project delivery advisory team for support with your agile programme.