PSPO-I: Professional Scrum Product Owner I

In Scrum, there is only one product and one Product Backlog for a given product. The Product Backlog is the single source of truth for the Scrum Team and the stakeholders. It contains all the requirements, features, functions, enhancements, fixes, and anything else that can deliver value to the customers and users of the product. The Product Backlog is ordered by the Product Owner based on the product vision, goals, and value.

Having multiple Product Backlogs for one product would create confusion, duplication, inconsistency, and waste. It would also make it harder to align the Scrum Teams and the stakeholders on the same product direction and priorities. Therefore, each Scrum Team should not have a separate Product Backlog.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. The Product Owner is responsible for managing and refining the Product Backlog, collaborating with the stakeholders and the Developers, and ordering the items in a way that best achieves goals and missions. The Product Owner represents the interests of everyone with a stake in the product and ensures that the Scrum Team works on the right things at the right time.

Having multiple Product Owners for one product would create conflicts, overlaps, gaps, and inefficiencies. It would also make it harder to maintain a clear and consistent product vision, strategy, roadmap, and backlog. Therefore, there should be only one Product Owner for one product.

In some cases, when there are multiple Scrum Teams working on one product, it may be necessary to have some form of scaling or coordination mechanism to ensure alignment and collaboration among the teams. However, this does not mean that there should be multiple Product Owners or Product Backlogs. Instead, there should be ways to facilitate communication, feedback, integration, and transparency among the teams and with the Product Owner. For example, some frameworks or practices that can help with scaling Scrum are Nexus, LeSS, SAFe, or Scrum of Scrums.

Scrum Guide: https://www.scrumguides.org/scrum-guide.html

Nexus: https://www.scrum.org/resources/what-is-nexus

LeSS: https://less.works/

SAFe: https://www.scaledagileframework.com/

Scrum of Scrums: https://www.agilealliance.org/glossary/scrum-of-scrums/

The "cone of uncertainty" is a graphical representation of the degree of uncertainty in a project estimate over time. It shows that the range of possible outcomes is wider at the beginning of the project and narrows down as the project progresses and more information becomes available.

The "cone of uncertainty" can be used to illustrate that as a project forecast lengthens, it is increasingly less certain. This means that the longer the time horizon for a project, the more variability and risk there is in the estimate. This also implies that shorter iterations and frequent feedback can help reduce uncertainty and improve accuracy.

The "cone of uncertainty" cannot be used to determine whether to cut quality, similar to the "Iron Triangle" of project management. The "Iron Triangle" is a model that shows the trade-offs between scope, time, and cost in a project. Quality is often considered as a fourth dimension that is affected by these three factors. Cutting quality is not a desirable option for any project, especially for Scrum projects that value delivering high-quality products that meet customer needs.

The "cone of uncertainty" cannot be used to determine the cost of a project before it begins. The cost of a project depends on many factors, such as the scope, the resources, the complexity, the risks, and the market conditions. The "cone of uncertainty" only shows the range of possible outcomes based on the available information at a given point in time. It does not provide a definitive or accurate estimate of the cost before the project starts.

The "cone of uncertainty" cannot be used to determine the length of the next Sprint. The length of the next Sprint is determined by the Scrum Team based on their empirical experience and their ability to deliver a potentially releasable Increment of value. The "cone of uncertainty" does not provide any guidance on how long a Sprint should be or how much work can be done in a Sprint.

Scrum Guide: https://www.scrumguides.org/scrum-guide.html

Cone of Uncertainty: https://www.agilealliance.org/glossary/cone-of-uncertainty/

The Developers are the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. The Developers are accountable for organizing and managing their work. Only the Developers can decide how to perform the work during the Sprint1. The Developers plan the work necessary to create an Increment that meets the Definition of Done during the Sprint Planning event. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers2. The Developers also inspect their progress toward the Sprint Goal and adapt their plan during the Daily Scrum1. The Developers are self-managing, which means they decide internally who does what, when, and how1. The Scrum Master, the Product Owner, the team manager, and the subject matter experts are not involved in determining how the work is performed during the Sprint. They may provide guidance, feedback, or support, but they do not interfere with the Developers' autonomy and accountability134.

Reference:

Scrum Guide

What is a Developer?

Who Determines How Work Is Performed During The Sprint?

What is Sprint Planning?

The Developers need a Sprint Goal because it gives them a common yet specific goal to focus on during the Sprint. This is because:

The Sprint Goal is a short-term objective that provides guidance and focus to the Scrum Team throughout the Sprint. It is a flexible and negotiable commitment that can be adjusted as more is learned throughout the Sprint.

The Developers are accountable for creating a "Done" Increment in every Sprint. They must ensure that every Product Backlog item they work on meets the Definition of Done before it is considered complete.

The Developers are self-managing professionals who organize and manage their own work. They decide how to best accomplish their work, rather than being directed by others outside the Scrum Team.

The Developers need a Sprint Goal to align their efforts and collaborate effectively as a team. The Sprint Goal helps them prioritize and optimize their work based on value and impact. The Sprint Goal also helps them cope with uncertainty and complexity by providing a clear direction and a shared purpose.

Other options, such as a Sprint Goal only giving purpose to Sprint 0, Sprint Goals being not valuable, or a Sprint Goal ensuring that all of the Product Backlog items selected for the Sprint are implemented, are not valid reasons why the Developers need a Sprint Goal. They may reflect a misunderstanding of what a Sprint Goal is or how Scrum works.

[Scrum Guide], page 15, section "Sprint Goal"

[Scrum Guide], page 7, section "Developers"

[Scrum Guide], page 10, section "Definition of Done"

[Scrum Guide], page 10, section "Increment"

The Scrum Team should have all the skills needed to turn Product Backlog items into a valuable, useful Increment, as this is the primary goal of each Sprint. The Scrum Guide states that 'The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies.It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.'1The Scrum Team should be cross-functional, which means that the Developers have all the skills necessary to create a product Increment.1The Scrum Team should also be self-managing, which means that they decide how best to accomplish their work, rather than being directed by others outside the Scrum Team.1

1: The Scrum Guide2, page 6

2:The Scrum Guide