PSM-III試験無料問題集「Scrum Professional Scrum Master level III (PSM III) 認定」
Learning turns into 'validated learning' when assumptions and goals can be assessed through results. What is a key way for a Product Owner to apply validated learning?
正解：
A key way aProduct Owner applies validated learningis byadapting the Product Backlog and Product Goal based on evidence from real outcomes, not assumptions.
Through inspection of:
* TheProduct Incrementduring the Sprint Review,
* Stakeholder and user feedback,
* Measured outcomes such as usage, value, or risk reduction,
the Product Owner assesses whether assumptions about value, users, or direction are valid. This learning becomesvalidatedonly when it is reflected inchanged decisions, such as:
* Reordering Product Backlog items,
* Adding or removing backlog items,
* Adjusting or even abandoning a Product Goal.
In other words, validated learning is applied when the Product Owneruses results to change what is built next, ensuring that future work is based on evidence rather than speculation.
Through inspection of:
* TheProduct Incrementduring the Sprint Review,
* Stakeholder and user feedback,
* Measured outcomes such as usage, value, or risk reduction,
the Product Owner assesses whether assumptions about value, users, or direction are valid. This learning becomesvalidatedonly when it is reflected inchanged decisions, such as:
* Reordering Product Backlog items,
* Adding or removing backlog items,
* Adjusting or even abandoning a Product Goal.
In other words, validated learning is applied when the Product Owneruses results to change what is built next, ensuring that future work is based on evidence rather than speculation.
Every Sprint has a Sprint Review. What is the purpose and result of this event?
正解：
TheSprint Reviewis a formal Scrum Event held at the end of each Sprint toinspect the outcome of the Sprint andadapt the Product Backlogif needed. Its primary purpose is to enable empirical decision-making by involving both theScrum Team and stakeholdersin inspecting the product and determining what to do next.
Purpose of the Sprint Review
The main purpose of the Sprint Review is toinspect the "Done" Product Incrementin the context of overall product progress. During this event:
* The Scrum Team presents the Increment that meets the Definition of Done.
* The Developers explain what was delivered, what was not delivered, and the challenges encountered.
* Stakeholders activelyinspect the product, often by using it, rather than reviewing documents or reports.
This inspection provides real, hands-on feedback and creates a shared understanding of the current state of the product and its direction.
Result of the Sprint Review
The Sprint Review results inheightened transparencyfor all participants. By jointly inspecting the Increment, new insights emerge about customer needs, market conditions, risks, and opportunities. These insights inform conversations aboutwhat is needed next.
Based on this shared understanding:
* TheProduct Owner collaborates with stakeholders and the Scrum Teamto adapt and update the Product Backlog.
* Completed work is accepted or further work is identified.
* New Product Backlog Items may be added, reordered, or refined to reflect the latest understanding of the product.
The Sprint Review does not aim to approve or reject work formally, but to enable learning and adaptation.
Purpose of the Sprint Review
The main purpose of the Sprint Review is toinspect the "Done" Product Incrementin the context of overall product progress. During this event:
* The Scrum Team presents the Increment that meets the Definition of Done.
* The Developers explain what was delivered, what was not delivered, and the challenges encountered.
* Stakeholders activelyinspect the product, often by using it, rather than reviewing documents or reports.
This inspection provides real, hands-on feedback and creates a shared understanding of the current state of the product and its direction.
Result of the Sprint Review
The Sprint Review results inheightened transparencyfor all participants. By jointly inspecting the Increment, new insights emerge about customer needs, market conditions, risks, and opportunities. These insights inform conversations aboutwhat is needed next.
Based on this shared understanding:
* TheProduct Owner collaborates with stakeholders and the Scrum Teamto adapt and update the Product Backlog.
* Completed work is accepted or further work is identified.
* New Product Backlog Items may be added, reordered, or refined to reflect the latest understanding of the product.
The Sprint Review does not aim to approve or reject work formally, but to enable learning and adaptation.
What would be an example of a development team member displaying unethical behaviour?
正解：
An example of unethical behaviour by a Development Team member in Scrum isknowingly delivering low- quality or non-secure softwarewhile being aware of the potential negative impact on users, stakeholders, or the organization. Such behaviour contradicts the ethical expectations embedded in Scrum and violates multiple Scrum Values.
For instance, a developer may intentionally ignore known defects, security vulnerabilities, or technical debt in order to finish work faster or appear more productive. Releasing software that is known to be insecure or unstable places end-users at risk and misrepresents the true state of the product. This underminesCommitment to quality andCourage, as the individual avoids addressing difficult issues or raising concerns.
Another unethical example iswithholding important informationfrom the Scrum Team or stakeholders. This may include hiding risks, downplaying impediments, or not being transparent about progress or challenges.
Such behaviour violatesOpennessand damages trust, which is essential for empiricism and effective collaboration.
Unethical behaviour may also be expressed throughfailing to support team members. For example, refusing to help others, dismissing or disrespecting colleagues' opinions, or working in ways that harm team cohesion contradicts the Scrum Value ofRespect. Scrum expects team members to collaborate and support each other in achieving the Sprint Goal.
Finally,going against agreements made by the Scrum Team, such as ignoring the Definition of Done or agreed working agreements, is unethical. This damages accountability and can mislead stakeholders about the quality and completeness of the work.
For instance, a developer may intentionally ignore known defects, security vulnerabilities, or technical debt in order to finish work faster or appear more productive. Releasing software that is known to be insecure or unstable places end-users at risk and misrepresents the true state of the product. This underminesCommitment to quality andCourage, as the individual avoids addressing difficult issues or raising concerns.
Another unethical example iswithholding important informationfrom the Scrum Team or stakeholders. This may include hiding risks, downplaying impediments, or not being transparent about progress or challenges.
Such behaviour violatesOpennessand damages trust, which is essential for empiricism and effective collaboration.
Unethical behaviour may also be expressed throughfailing to support team members. For example, refusing to help others, dismissing or disrespecting colleagues' opinions, or working in ways that harm team cohesion contradicts the Scrum Value ofRespect. Scrum expects team members to collaborate and support each other in achieving the Sprint Goal.
Finally,going against agreements made by the Scrum Team, such as ignoring the Definition of Done or agreed working agreements, is unethical. This damages accountability and can mislead stakeholders about the quality and completeness of the work.
When working on one software product with multiple Scrum teams in Scrum Nexus, what is important about dependenciesof the planned Backlog Items and integration of the work being done?
正解：
When multiple Scrum Teams work together on a single product usingScrum Nexus, managing dependencies and ensuring effective integration are critical to delivering a usable Increment each Sprint. Scrum Nexus extends Scrum by explicitly addressing the complexity that arises from multiple teams working on the same product.
First,dependencies between teams should be minimized. Dependencies reduce autonomy, slow feedback, and increase risk. In Nexus, Product Backlog Items should be ordered and refined in such a way that work with strong dependencies is keptwithin a single team whenever possible. This supports cross-functionality at the team level and reduces the coordination overhead required between teams.
Second, when dependencies cannot be avoided, they must be madetransparent and actively managed. The Nexus framework encourages early identification of dependencies during Nexus Sprint Planning so that teams can coordinate their work effectively. However, the goal remains to continuously reduce dependencies over time through better backlog ordering, architecture improvements, and skill broadening.
Third,integration of work is vital and takes precedence over completing all planned work. In Scrum Nexus, an Increment is only considered "Done" when the work of all teams is fully integrated and meets the shared Definition of Done. Unintegrated work, even if technically complete by an individual team, does not provide value and increases risk.
Fourth, integration must occurearly and often during the Sprint, not only at the end. Continuous integration helps uncover issues sooner, supports frequent inspection, and enables timely adaptation. Delaying integration increases the likelihood of defects, rework, and failure to produce a usable Increment.
First,dependencies between teams should be minimized. Dependencies reduce autonomy, slow feedback, and increase risk. In Nexus, Product Backlog Items should be ordered and refined in such a way that work with strong dependencies is keptwithin a single team whenever possible. This supports cross-functionality at the team level and reduces the coordination overhead required between teams.
Second, when dependencies cannot be avoided, they must be madetransparent and actively managed. The Nexus framework encourages early identification of dependencies during Nexus Sprint Planning so that teams can coordinate their work effectively. However, the goal remains to continuously reduce dependencies over time through better backlog ordering, architecture improvements, and skill broadening.
Third,integration of work is vital and takes precedence over completing all planned work. In Scrum Nexus, an Increment is only considered "Done" when the work of all teams is fully integrated and meets the shared Definition of Done. Unintegrated work, even if technically complete by an individual team, does not provide value and increases risk.
Fourth, integration must occurearly and often during the Sprint, not only at the end. Continuous integration helps uncover issues sooner, supports frequent inspection, and enables timely adaptation. Delaying integration increases the likelihood of defects, rework, and failure to produce a usable Increment.