With the 2020 update to the Scrum Guide, three commitments were added to the artifacts. The idea of a commitment is to provide additional quality to the artifact to improve transparency. In the case of Product Backlog, the commitment is to the Product Goal.
What is a Product Goal?
In a nutshell, the Product Goal provides context to the Product Backlog. It can be thought of as the ‘why’ we are doing all of this work. It can be used as the elevator pitch to ‘what is the Scrum Team working on?’. The word Goal is intentional as it describes two things:
- It is something to strive for, and
- It is measurable when you have attained it.
The Scrum Guide does not prescribe what the details of a Product Goal are thereby allowing Scrum Teams to form the goal in the right way for their context. For instance, some Scrum Teams may work to a quarterly Product Goal that is very focused, another Scrum Team might have a Product Goal that is very aspirational and high level. Context is everything when determining the Product Goal.
Here are some of the characteristics of a Product Goal:
- The development of the Product Goal, like everything in Scrum, evolves with the definition of the Product Backlog and the Product Goal helps to drive the evolution of the Product Backlog.
- There is only one Product Goal for the Product Backlog at any one time. Of course, this could be considered semantics as to how the Product Goal is described may address multiple objectives. However, a good practice is that the Product Goal is clear and concise.
- A Product Goal can be complete without all of the Product Backlog items (PBIs) being completed. It is likely that as value is delivered through a series of Sprints that the understanding of the Product Goal will be refined. This is complex work and that by its very nature is unclear and full of surprises.
- A handy symmetry is that the Product Goal is to the Product Backlog as the Sprint Goal is to the Sprint Backlog.
- A Product Strategy or Product Roadmap often provides a directional plan for realizing the Product Goal. Of course, this is dependent on the context as it is possible that this plan is adequately described in the Product Backlog.
- As each Increment is produced, the Product incrementally moves toward the Product Goal. How that value is incrementally determined is very context-specific. For example, in the case of SpaceX, the Product Goal for Falcon Heavy is to deliver 5 astronauts to the International Space Station (ISS). Each Sprint they move closer to that goal even if the actual usage of the product is not possible until launch day. For other products, it is much easier to see incremental progress toward the Product Goal even with multiple deliveries during a Sprint.
- The Product Goal is made transparent in the Product Backlog in the same way that the Sprint Goal is made transparent in the Sprint Backlog. Each Scrum Team will do what is necessary to make this happen depending on their environment.
- The Sprint Review will review the Increment in the context of both the Sprint Goal and the Product Goal. This encourages Sprint Reviews to put some context around their findings and ask questions about how much progress has been made toward the Product Goal. These findings will be very useful in Sprint Planning as they can help create focus and form decisions about the next Sprint.
The Product Goal is therefore a simple directional statement that provides context and purpose for the Scrum Team and Stakeholders for the work. And depending on the context of how that Product Goal is described, measured, updated, and depreciated will change. However, some common questions can help us understand the intent of the Product Goal.
Can a Product Goal change during a Sprint?
For the majority of situations, the Product Goal is described in a way that it will require multiple Sprints to realize. That means, like the Sprint Goal it is likely that the Product Goal does not change during a Sprint. It is possible that the Scrum Team, by doing work discovers something that invalidates the Product Goal, in the same way that a Scrum Team can discover something that invalidates the Sprint Goal. When that happens the context of the situation or the environment the team is working in will influence what happens next. Some teams will stop the Sprint (which is the decision of the Product Owner) and go back to the stakeholders and present their findings. Other Scrum Teams will refine the Product Goal and the Sprint Goal validating them at the next Sprint Review. And other Scrum Teams will do something else. The Scrum Guide does not describe exactly what happens in these situations believing that the Scrum Team will make the right decision depending on the situation.
Who decides the Product Goal?
The Product Goal is part of the Product Backlog which the Product Owner is accountable for. The Product Owner is therefore accountable for the Product Goal in the same way they are accountable for the Product Backlog. Ultimately the Product Goal describes, at a high level the value of the work that the Product Owner is accountable for. The Scrum Guide clearly describes the accountabilities of the Product Owner as:
“Developing and explicitly communicating the Product Goal.”
What is the relationship between Product Goal and Vision?
In the 2017 version of the Scrum Guide vision is only mentioned once in the context of the Increment.
“The increment is a step toward a vision or goal.”
In the 2020 version of the Guide, the reference to vision has been removed with the Product Goal being added to provide more clarity and focus for the Scrum Team. At its core, Scrum is still a framework for encouraging teams to incrementally make progress toward a goal and that has not changed. And depending on the situation there might still be a vision document that describes the Product Goal in more detail or the product vision describes a much higher level narrative where the Product Goal is the first step towards that much bigger vision.
Context is everything when using terms like vision, mission, and strategy. Each organization or person will have their own context when those words are used. The Product Goal is the minimal thing that a Scrum Team needs in order to work on their Product Backlog and get started. If that Product Goal is inspired by a vision or narrative that is even better, but it is outside of the scope of the Scrum Guide.