Product Goal in relation to Product Backlog & Product Vision

There are three commitments (Product Goal, Sprint Goal, and Definition of Done) were added to the artifacts. Product Goal provides additional quality to the artifact to improve transparency. For Product Backlog, the commitment is the Product Goal. These are a set of tangible and measurable expressions of what success looks like for a product. It connects Product Strategy and Product Execution by providing teams with a concrete and holistic set of metrics, so they know if they are moving in the right direction and can adjust their actions if needed.

Describes a future state of the product that can serve as a target for the Scrum Team to plan against. It is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Goal.  A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract. It is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next. In a nutshell 

1. Product Goal is something that scrum team must strive for.
2. It is measurable when scrum team have attained it.
3. Product Goal is to the Product Backlog as the Sprint Goal is to the Sprint Backlog.

Characteristics of Product Goal

• Evolves with the definition of the Product Backlog and it helps to drive the evolution of the Product Backlog.
• It is clear, concise & only one Goal for the Product Backlog at any point of time.
• Stepping stones towards the Product Vision. Product Goals are a result of responding to emerging market conditions rather than an abstraction of work.
• It 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 Goal will be refined. This is complex work and that by its very nature is unclear and full of surprises.
• A Product Strategy or Product Roadmap often provides a directional plan for realizing the 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 Goal. How that value is incrementally determined is very context-specific.
• It 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 Goal. These findings will be very useful in Sprint Planning as they can help create focus and form decisions about the next Sprint.

Methods & Techniques for creating a Product Goal

It’s a good idea to follow the SMART methodology that will provide you with detailed guidelines.

S = Specific, Significant, Stretching, Sustainable – means that it should be relevant throughout the project. The team should check whether the goal could be followed and sustained throughout the product development. They should also check if the goal could be broken down into smaller sections or could be changed if necessary. 

M = Measurable, Meaningful, Motivational –  visible and measurable. The team should be able to count how much of the goal is being achieved by using a tracking system or a check-in system. Hence, the team should be able to see the progression in the goals by measuring them periodically. 

A = Agreed upon, Attainable, Achievable, Acceptable, Action-Oriented – attainable and should not be made based on abstract thoughts and desires. The team has to think about whether they could develop the product features effectively without any bugs. All of the obstacles that they might face while attaining the goal must be listed and discussed. 

R = Realistic, Relevant, Reasonable, Rewarding, Results-Oriented – Product Goal should be designed in such a way that it is humanly possible to achieve it.

T = Time-based, Time-bound, Timely, Tangible, Trackable – The period allotted for the goal to complete should also be taken into consideration and whether it could be achieved in the given time. Lesser time to achieve bigger goals may not be possible and would put undue pressure on the Scrum Team members.

Use any of the below methods to craft Product Goals:

• The Lean UX Canvas
• Product Strategy Canvas
• Product Vision Template
• Kickstart Catalogue
• Business Model Canvas
• Value Proposition Canvas

Examples of Product Goal

Here are a few examples of high-level product goals that will help you drive your product forward:

• Become #1 work and data management platform by 2025
• Become a $1 billion company by January 2024
• Develop an exceptionally secure and trustworthy application by 2023
• Reach 1 million users by Q1 2025
• To improve the customer experience by next year improving the NPS.
• Reaching 5,000 new users by the next 6 months.
• Increasing user retention by at least 20%

Relationship between Product Goal & Sprint Goal

A Sprint Goal is a commitment in the scrum. It is the objective that is set for the sprint that gives guidance to the developers on why they are building the increment.

• Sprint Goals and Product Goals are compatible and complement each other.
• Scope and Sprint Plan is flexible in Scrum, the Sprint Goal is not. The Sprint Goal helps to prevent meeting the plan becoming more important than meeting the objective.
• Sprint Goal is agreed upon by whole Scrum Team, to get buy-in and commitment from the whole team.
• Kanban and Scrum are compatible with each other, so you can use Kanban to improve your flow if you want.
• Commitment to a fixed Sprint Goal is a good thing. A Sprint Goal promotes teamwork, focus and collaboration. No commitment to anything is not a valid alternative. Commitment to goals is necessary for high-performing teams to become high-performing.
• Failure to meet the Sprint Goal is not something that should be punished, it’s something to learn from. Scrum doesn’t tell to punish teams when they fail to meet the Sprint Goal. If anything, Scrum shifts the focus to learning from it through the Sprint Review and the Sprint Retrospective.

Product Vision

A Product Vision is an idea that lasts throughout the product, hence, it needs to be a sustainable idea continuingly. Here are some features of a sustainable Product Vision:

• The Product Vision should be visible and transparent such that everyone on the Scrum team could “see” it and understand it whenever needed.
• The Vision should be reviewed periodically so that they could evaluate whether whatever was envisioned in an earlier time, is still relevant, practical, and viable now.

Product Vision vs Product Goal

Product Vision	Product Goal
Abstract thought or idea from the client before the development of the product.	Measurable, and sustainable result or outcome which the product has to accomplish
It is a statement that lays the purpose on which the Product Goals are decided.	It is derived from the Product Vision which is designed for the team members to achieve.
It is an overall picture of what the product intends to achieve.	It is many smaller objectives the product has to fulfill for the Product Vision to be achieved.
It is not evaluated based on a given time period.	It has to be completed within a time period such that the team moves on to the next goal.
It is the client’s version of the idea of the product and could be high-end and abstract.	It has to have five elements of SMART- Sustainable, Measurable, Attainable, Realistic, and Time-based.

Frequently Asked Questions

Question: Who is accountable for Product Goal?

Answer: It is in the Product Backlog for which the Product Owner is accountable. The Product Owner is therefore accountable for the Goal in the same way they are accountable for the Product Backlog. The Product Owner is accountable for the development and communication of the Goal; however, they would work with the Scrum Team and stakeholders to make sure that it is clear and easy to understand. 

Question: Can a Product Goal change during a Sprint?

Answer: Product Goals are created to provide context to the Product Backlog. So it is for multiple sprints and it is likely that it does not change during a Sprint. It is possible that the Scrum Team may discover something that invalidates the Goal like sometimes it invalidates the Sprint Goal. If there is a significant change in context and the current Goal has not been achieved then the Scrum Team would replace the Goal with a more fitting one. If this change to the Goal happens in a Sprint it remains in the authority of the Product Owner to cancel the Sprint if the goal of Sprint no longer aligns with the updated Goal.

Question: How frequently should you change the Product Goal?

Answer: It is a strategic vision, and the frequency of updates will reflect your situation and context. 

Question: Relationship between Product Vision and Goal?

Answer: The product vision can describes the Goal in more detail or describes a much higher level narrative where it is the first step towards that much bigger vision. It is the minimal thing that a Scrum Team needs in order to work on their Product Backlog and get started.