PSM II Practice Exam — PSM II : Master™ II

This question assesses PSM II candidates' understanding of the Scrum Master's formal management accountabilities as defined in the Scrum Guide, a core domain for the certification. Unlike traditional people or product management roles, the Scrum Master's management responsibilities are focused on enabling effective Scrum adoption, process adherence, and barrier removal rather than controlling team members, product scope, or performance reporting. The three correct options align directly with official Scrum Master accountabilities outlined in the 2020 Scrum Guide, while incorrect options describe responsibilities owned by other Scrum roles or the full Scrum Team. Option Analysis: A. Incorrect. Reporting on Sprint performance is a shared accountability of the entire Scrum Team during the Sprint Review, not a management responsibility of the Scrum Master. The Scrum Master facilitates transparency of performance outcomes but does not own or manage performance reporting for the team. B. Correct. Per the Scrum Guide, the Scrum Master is formally accountable for establishing Scrum as defined across the organization, which includes coaching teams and stakeholders on correct Scrum understanding, addressing misalignment in Scrum enactment, and driving organizational change to support effective Scrum implementation. This is a core cross-organizational management accountability of the role. C. Incorrect. Managing individual developer capacity and utilization is not a Scrum Master responsibility. Scrum Teams are self-managing, so developers own their own work allocation, capacity planning, and utilization tracking. This describes a traditional people management function that is not part of the Scrum Master's official accountabilities. D. Correct. The Scrum Master manages the process of Scrum application, including facilitating Scrum events as requested or needed, coaching the team on Scrum rules and practices, and supporting continuous improvement of the team's Scrum process to deliver higher value. This is explicitly a core management responsibility of the role. E. Incorrect. Managing Product Backlog items is the exclusive accountability of the Product Owner, and managing work in the Sprint Backlog is owned exclusively by the self-managing developers. The Scrum Master has no authority to modify or manage backlog content, so this option is incorrect. F. Correct. Removing organizational impediments that block the team's progress and productivity is a key management accountability of the Scrum Master. As a leader with cross-organizational influence, the Scrum Master addresses systemic barriers that the team cannot resolve independently, which falls under their remit of managing supportive systems for Scrum delivery. Key Concepts: 1. Scrum Master Accountabilities: The 2020 Scrum Guide defines three sets of Scrum Master accountabilities focused on serving the Scrum Team, Product Owner, and broader organization, including process management, Scrum adoption, and impediment removal as core management responsibilities. 2. Self-Managing Scrum Teams: Scrum Teams are self-managing, meaning they own internal work allocation, capacity planning, and Sprint Backlog execution, so the Scrum Master never manages individual team members or their assigned work. 3. Servant Leadership for Scrum Masters: The Scrum Master's management authority is applied to enable team success rather than direct output, so their management responsibilities are limited to process, adoption, and barrier removal, not people or product scope control. References: The 2020 Scrum Guide, https://scrumguides.org/scrum-guide.html Professional Scrum Master II Certification Learning Objectives

When transitioning from siloed component teams to cross-functional Scrum teams, the process follows established team development and change management principles core to the PSM II curriculum. Cross-functional teams eliminate costly handoffs between specialized silos, improving end-to-end value delivery, but newly formed teams require an adjustment period before reaching optimal performance. The two correct options acknowledge that temporary productivity impacts are normal and expected during this transition, while emphasizing that business value delivery still improves compared to the legacy siloed model, which is a critical expectation for organizations adopting Scrum to understand to avoid abandoning the transition prematurely due to unrealistic initial performance targets. Option Analysis: A. Incorrect. Scrum explicitly discourages comparing performance between different Scrum Teams, as each team operates with unique context, skill sets, backlog complexity, and stakeholder needs. Performance comparisons create unhealthy competition, erode collaboration between teams, and contradict the Scrum value of openness. Additionally, Scrum Teams are self-managing and choose their own work, rather than having tasks assigned to them based on performance comparisons, so this option is misaligned with core Scrum principles. B. Correct. This aligns with Tuckman's stages of team development, a key concept tested in PSM II. New cross-functional teams go through forming and storming stages as they build trust, align on working agreements, and learn to collaborate across former silos. While productivity is temporarily lower during these initial stages, the elimination of siloed handoffs means the team delivers usable, end-to-end business value faster than the legacy component team model, leading to higher overall value delivery even during transition. C. Incorrect. Scrum adoption does not require fully mature feature teams to begin. Organizations can adopt Scrum practices incrementally while gradually restructuring teams to become more cross-functional over time. Postponing Scrum adoption until perfect team structures are in place contradicts the Scrum principle of iterative improvement, and ignores that teams become more cross-functional through practicing Scrum, not before they start. D. Correct. Team members from specialized silos are accustomed to working independently on their component of work before handing it off to another team. In a cross-functional team, members must learn to collaborate continuously, align on shared sprint goals, and take collective ownership of end-to-end functionality. This adjustment to new working patterns and shared responsibility takes time, leading to temporary lower productivity as the team matures, which is a normal and expected part of the transition. Key Concepts: 1. Tuckman's Team Development Model: This framework describes the stages new teams move through (forming, storming, norming, performing) as they mature, with lower initial productivity that improves as the team builds trust and aligned working practices, a core concept for managing team transitions in PSM II. 2. Cross-Functional Scrum Teams: A core Scrum definition stating that Scrum Teams have all skills necessary to produce a potentially releasable Increment each Sprint, eliminating wasteful handoffs between siloed teams and accelerating end-to-end value delivery. 3. Change Management for Scrum Adoptions: PSM II curriculum emphasizes that transitions from traditional work models to Scrum involve temporary productivity dips as teams adapt to new structures, roles, and practices, which leadership must anticipate and support rather than penalize. References: Scrum Guide 2020, https://scrumguides.org/scrum-guide.html Professional Scrum Master II Learning Path

This scenario addresses common gaps in transparency and adherence to Scrum's core requirements for usable, potentially releasable Increments. The root problems are twofold: first, the reported velocity of 40 units per Sprint is invalid, as it counts work that does not meet the Definition of Done (missing required integration tests), so Paul's initial progress assumptions are incorrect. Second, the original 9-Sprint estimate was based on velocity from an unrelated previous product, which does not account for this new product's unique integration testing requirements. Option B is the most effective approach because it prioritizes full transparency, addresses the existing backlog of undone work, establishes accurate forecasting based on the team's actual context, and respects formal Scrum accountabilities. The Development Team fulfills their responsibility to disclose the true state of work and provide accurate effort estimates, while Paul, as Product Owner, is given complete, accurate information to make an informed value-based decision on whether to continue the project or cancel it to avoid wasting budget and resources on a product that may no longer deliver sufficient ROI. Option Analysis: A. Incorrect. Scrum requires every Sprint to produce a potentially releasable Increment that fully meets the team's Definition of Done, not a 90% completion threshold. Deferring undone work to the final Sprint accumulates significant technical debt and delivery risk, and continues to report inaccurate velocity that does not reflect actual shippable work. This approach violates core Scrum quality and transparency rules. B. Correct. This option fully aligns with Scrum values and accountabilities. The Development Team demonstrates transparency by disclosing that existing Increments are not releasable, provides an accurate estimate of the effort required to bring existing undone work into compliance with the Definition of Done, and re-estimates all remaining Product Backlog items to include required integration testing effort. This gives the Product Owner complete visibility into actual progress and total remaining effort, allowing him to make a fully informed decision on whether the project still delivers enough value to continue, which is a core Product Owner accountability. C. Incorrect. Scrum Teams are self-managing, so the Scrum Master has no authority to manage the Sprint Backlog or assign work to individual Development Team members. Tracking unused budget resources is also not a Scrum Master responsibility, and this approach completely fails to address the core problem of undone work and inaccurate progress reporting. This violates fundamental Scrum team structure and accountability rules. D. Incorrect. The Scrum framework does not recognize separate "release Sprints". Every Sprint is required to produce a potentially releasable Increment that meets the Definition of Done. Setting aside undone work for dedicated release Sprints accumulates unnecessary risk and maintains the lack of transparency around actual progress. Additionally, securing additional funding for Sprints is not a responsibility the Scrum Master assigns to the Product Owner; the Product Owner makes funding and continuation decisions based on transparent value and progress data. This approach is inconsistent with core Scrum framework guidelines. Key Concepts: 1. Definition of Done: The formal, shared understanding of all work required for an Increment to be usable and potentially releasable. Only work that fully meets the Definition of Done may be counted in velocity, as incomplete work reduces transparency and increases delivery risk. 2. Scrum Accountabilities: The Product Owner is accountable for maximizing product value and making go/no-go decisions for the product based on accurate progress and cost data. The Development Team is accountable for the quality of Increments and providing transparent, accurate effort estimates. The Scrum Master serves as a coach rather than a manager, and does not assign work or direct the Development Team's activities, as Scrum Teams are self-managing. 3. Valid Velocity Forecasting: Velocity is a team-specific metric that reflects the amount of Done work a team can complete in a Sprint. Velocity from past or unrelated projects is not a reliable forecasting tool for new products, as differences in work complexity, integration requirements, and team context will change the amount of work the team can complete per Sprint. References: Scrum Guide 2020, https://scrumguides.org/scrum-guide.html What is Velocity?

The scenario describes a common misapplication of the Daily Scrum event, where the Development Team is treating the event as a status reporting session to the Product Owner instead of using it for their own daily alignment toward the Sprint Goal. For PSM II, the Scrum Master’s core accountability is to foster understanding of Scrum theory and practice across the Scrum Team, rather than imposing top-down solutions. The root cause here is a gap in both the Product Owner and Development Team’s understanding of the purpose of the Daily Scrum and event ownership in Scrum. Coaching both parties to understand the intended design of Scrum events empowers the self-managing Scrum Team to identify and implement the most appropriate solution for their context, whether that means the Product Owner only attends the Daily Scrum when invited to provide specific input, or the Development Team adjusts their interaction to focus on their own alignment rather than reporting status. This approach aligns with the Scrum Master’s servant leadership role as defined for PSM II, addressing the root cause rather than just symptomatic issues. Option Analysis: A. This option is incorrect. While the Daily Scrum is owned by the Development Team, the Product Owner is not explicitly barred from attending if they are invited and their presence adds value. Simply asking Paul to stop attending does not address the underlying issue of both parties misunderstanding the purpose of the Daily Scrum, and it runs counter to the Scrum Master’s coaching-focused approach, as it imposes a solution instead of enabling the team to make their own informed decision. B. This option is correct. PSM II emphasizes that the Scrum Master acts as a coach to build the Scrum Team’s capability to apply Scrum effectively. Coaching both the Product Owner and Development Team on the purpose of Scrum events ensures they understand that the Daily Scrum exists to help the Development Team align on progress toward the Sprint Goal, not to provide status updates to stakeholders. Equipping the team with this understanding allows them to self-organize and decide the most appropriate next steps, supporting long-term adherence to Scrum values and self-management. C. This option is incorrect. While the Product Owner is accountable for product success, this does not give them authority to co-opt the Development Team’s event for status reporting. Allowing this misapplication of the Daily Scrum reduces the event’s effectiveness for the Development Team, undermines their self-management, and violates the design of Scrum events as defined in the Scrum Guide. D. This option is incorrect. Facilitating the Daily Scrum to avoid conflict is a short-term, symptomatic fix that does not address the root cause of misaligned understanding of the event’s purpose. The Scrum Master only facilitates Scrum events as requested or needed, and long-term, the Development Team should be empowered to run their own Daily Scrum. This approach also does not build the team’s capability to address similar gaps in Scrum application in the future. Key Concepts: 1. Scrum Master as Servant Leader and Coach: A core PSM II competency, this accountability requires the Scrum Master to support the Scrum Team by building their understanding of Scrum theory and practice, rather than enforcing rules or making decisions for the team. This approach fosters long-term self-sufficiency and adherence to Scrum values. 2. Daily Scrum Purpose and Ownership: The Daily Scrum is an event exclusively for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog for the next 24 hours of work. It is owned by the Development Team, and other attendees including the Product Owner may only be present if invited by the team to provide specific, relevant input. 3. Scrum Team Self-Management: Scrum Teams are self-managing, meaning they have the authority to decide how to accomplish their work, including how to structure and run their own events. The Scrum Master supports this by removing impediments and building the team’s Scrum expertise, rather than directing their actions. References: The 2020 Scrum Guide, https://scrumguides.org/scrum-guide.html Professional Scrum Master II Learning Path

The Scrum Master operates as a servant leader and coach rather than a decision-making authority or passive bystander in Scrum events and team decisions. Altering the Definition of Done to remove regression testing carries material implications for product quality, transparency, and the core Scrum requirement of delivering potentially shippable increments each Sprint. The appropriate actions in this scenario align with the Scrum Master’s accountability to uphold Scrum pillars, surface hidden tradeoffs, and support the Product Owner and Development Team in making informed, intentional choices. Rather than unilaterally rejecting or automatically approving the proposed change, the Scrum Master asks probing questions to ensure the team understands both the root problem driving the change and the downstream impacts of removing regression testing from the Definition of Done, while confirming the change does not compromise the team’s ability to deliver usable, valuable increments. Option Analysis: A. Incorrect. The Scrum Master does not hold the authority to unilaterally reject a decision agreed to by the Product Owner and Development Team regarding the Definition of Done. While removing regression testing may introduce long-term maintainability risks, the Scrum Master’s role is to coach the team to recognize these tradeoffs, not veto their decision outright. This approach fails to respect team autonomy and does not address the root problem driving the proposed change. B. Incorrect. The Scrum Master cannot blindly accept a decision solely because the Product Owner and Development Team reached mutual agreement. The Scrum Master has a core accountability to uphold Scrum’s pillars of transparency, inspection, and adaptation, and to ensure the team understands the full impact of their choices. Rubber-stamping this change without exploring risks fails to fulfill these accountabilities, and may lead to eroded product quality and reduced transparency for stakeholders. C. Correct. This action aligns with the Scrum Master’s coaching and facilitation accountabilities. Probing to identify the root problem the team is trying to solve, and asking them to explicitly consider the impact of the change on transparency (as the Definition of Done is a key transparency artifact for all stakeholders) and product quality, helps the team make intentional, fully informed decisions rather than reacting to short-term pressures without accounting for long-term tradeoffs. This approach upholds the Scrum pillar of inspection by bringing hidden assumptions and risks to the surface. D. Correct. The core purpose of the Definition of Done is to define the criteria required for an increment to be considered potentially shippable, meaning it is in a usable state that the Product Owner could choose to release to end users immediately. Asking the Product Owner and Development Team to confirm that removing regression testing still allows them to deliver a potentially shippable increment ensures their decision aligns with the primary goal of every Sprint: delivering a valuable, usable increment of product functionality. Key Concepts: 1. Definition of Done: The Definition of Done is a shared, formal description of the state an increment must reach to be considered complete and fit for use. It establishes the product’s quality bar, supports consistent transparency across all stakeholders, and ensures a shared understanding of what work is required to deliver a potentially shippable increment. Changes to the Definition of Done must be evaluated for their impact on quality, transparency, and releasability. 2. Scrum Master Accountabilities: The Scrum Master serves the Scrum Team and organization by coaching teams to adhere to Scrum theory, practices, and values, facilitating productive conversations, surfacing hidden risks and tradeoffs, and removing impediments to the team’s progress. The Scrum Master is not a team manager or decision-maker, but a servant leader that supports the team in making autonomous, informed decisions. 3. Potentially Shippable Increment: Every Sprint’s objective is to deliver a potentially shippable increment of product functionality that meets the Definition of Done. This increment must be complete enough that the Product Owner can choose to release it to end users immediately, with no additional work required. Any adjustment to the Definition of Done must not compromise the team’s ability to deliver this standard of increment each Sprint. References: The 2020 Scrum Guide, https://scrumguides.org/scrum-guide.html Professional Scrum Master II Learning Path, https://www.scrum.org/courses/professional-scrum-master-ii-training