Ace Your PSPO-I PSPO Exam

The Scrum Master should talk to the IT manager and explain that progress in Scrum comes from inspecting an Increment at the Sprint Review. This is because:

• The Scrum Team is self-managing and does not need to report to anyone outside the team1.
• The Sprint Review is an event where the Scrum Team and the stakeholders collaborate on the product and inspect the Increment2.
• The Increment is a concrete and usable outcome of the Sprint that provides a measure of progress and value delivery3.
• The IT manager can attend the Sprint Review as a stakeholder and provide feedback on the product and the process4.

References:

• Scrum Guide, page 7, section “The Scrum Team”
• Scrum Guide, page 13, section “Sprint Review”
• Scrum Guide, page 10, section “Increment”
• Scrum Guide, page 14, section “Sprint Review”

• 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.

References:

• 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 Product Owner wants the Developers to adhere to its Definition of Done to have complete transparency into what has been done at the end of each Sprint. This is because:

• The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It is a shared understanding among the Scrum Team and the stakeholders of what “Done” means for any Product Backlog item that is selected for a 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 Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They must inspect the Increment at the end of each Sprint and assess how it delivers value and contributes to the Product Goal.
• Having a clear and consistent Definition of Done helps the Product Owner have complete transparency into what has been done at the end of each Sprint. It also helps them make informed decisions about releasing, adapting, or continuing the product development.

Other options, such as predicting the team’s productivity over time, knowing what the team will deliver over the next three Sprints, or reprimanding the team when they do not meet their velocity goal for the Sprint, are not valid reasons for wanting the Developers to adhere to its Definition of Done. They may reflect a misunderstanding of what a Definition of Done is or how Scrum works.

References:

• [Scrum Guide], page 10, section “Definition of Done”
• [Scrum Guide], page 7, section “Developers”
• [Scrum Guide], page 6, section “Product Owner”

• An Increment is a concrete stepping stone toward the product vision. It is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done”, which means it meets the Definition of Done and is usable.
• The Scrum Team decides when and how to release an Increment to customers or users. The Product Owner is responsible for maximizing the value of the product and the work of the Developers, and may decide to release an Increment at any time during or after a Sprint. The Developers are responsible for creating a potentially releasable Increment each Sprint, and may collaborate with the Product Owner and the stakeholders to determine the best way to deliver value.
• Releasing an Increment to customers or users is not mandatory at the end of each Sprint. The Scrum Team may choose to release an Increment more or less frequently, depending on the product goals, market conditions, customer feedback, or technical feasibility. However, releasing an Increment regularly can provide many benefits, such as:

References:

• Scrum Guide: https://www.scrumguides.org/scrum-guide.html
• Increment: https://www.scrum.org/resources/what-is-an-increment
• Releasing Value: https://www.scrum.org/resources/blog/releasing-value