Scrum Scrum Master Certified SMC New Questions

Statements I and II correctly describe how the Scrum Core Team can originate proposed changes. SBOK explains that ongoing interaction among the Product Owner, Scrum Master, Scrum Team, and stakeholders may lead Scrum Core Team members to suggest changes or product improvements. Recommendations commonly arise while creating deliverables, during Daily Standups, and particularly through the Retrospect Sprint process.

Statement IV is incorrect because the Scrum Master does not finalize formal Change Requests. The Product Owner has the decision authority to determine which suggested changes should become formal Change Requests and how approved changes should be prioritized in the Prioritized Product Backlog.

Statement III is not the applicable SBOK responsibility in the form stated here. Escalation beyond defined tolerances can involve other organizational authorities, but that does not make the Scrum Master the authority for finalizing or approving the change.

Thus, the technically supported statements are I and II. This also reinforces Scrum's separation between proposing/facilitating change and business prioritization/approval.

Study Guide reference: Change - > Change Requests - > Scrum Core Team; Retrospect Sprint; Product Owner authority over Prioritized Product Backlog.

========

SBOK defines six non-negotiable Scrum principles:

1. Empirical Process Control

2. Self-organization

3. Collaboration

4. Value-based Prioritization

5. Time-boxing

6. Iterative Development

Collaboration is therefore a Scrum principle and focuses on awareness, articulation, appropriation, and shared value creation. Value-based Prioritization ensures that the project continuously focuses on work producing the greatest business value. Iterative Development allows teams to repeatedly build, inspect, obtain feedback, and adapt to changing requirements.

Manage by Stages is not an SBOK Scrum principle. It is terminology associated particularly with PRINCE2's project-management principles, where a project is planned, monitored, and controlled stage by stage.

Although Scrum does divide work into Sprints, this should not be confused with the “Manage by Stages” principle. Scrum Sprints are iterative, adaptive development cycles rather than traditional management stages.

Therefore, C is not one of SBOK's six Scrum principles.

Study Guide reference: Principles - > Six Scrum Principles.

========

The Initiate phase establishes the foundation of the Scrum project. SCRUMstudy identifies its processes as Create Project Vision, Identify Scrum Master and Business Stakeholder(s), Form Scrum Team, Develop Epic(s), Create Prioritized Product Backlog, and Conduct Release Planning. Therefore, identifying the Scrum Master and relevant stakeholders is explicitly an Initiate-phase activity.

The remaining options belong to later phases. Estimating and committing User Stories form part of Plan and Estimate, where requirements selected from the Prioritized Product Backlog are analyzed, estimated, and committed for upcoming Sprint work. Conduct Daily Standup belongs to Implement, because it occurs while the Scrum Team is executing Sprint work and synchronizing daily activities.

This phase separation is important in SMC questions. Initiate establishes the vision, roles, high-level requirements, prioritized backlog, and initial release structure. Plan and Estimate converts prioritized requirements into executable Sprint-level work. Implement concerns actual creation of deliverables and daily coordination.

Accordingly, Identify Scrum Master and Stakeholder(s) is the only option that is explicitly part of the Initiate phase.

Study Guide reference: Initiate - > Identify Scrum Master and Business Stakeholder(s); Plan and Estimate - > Estimate/Commit User Stories; Implement - > Conduct Daily Standup.

========

A Piloting Plan is used when an organization wants to deploy a product or release initially to a controlled group before broader implementation. According to the SBOK glossary, such a plan can specify the scope and objectives of deployment, the target deployment user base, deployment schedule, transition arrangements, user preparation, evaluation criteria, and other deployment-related details.

The target user base is particularly important because a pilot must clearly identify who will receive and evaluate the initial deployment. Without a defined population, feedback cannot be interpreted reliably, operational impact cannot be controlled, and the organization cannot determine whether the pilot results are representative of the intended implementation.

Security concerns may certainly matter to a specific project, but they are not the defining element tested here. Likewise, employee-friction guidelines and synchronization methods are not identified as the fundamental element of a Piloting Plan in this context.

Therefore, specifying the target deployment user base is the choice that directly corresponds to SBOK's description of an effective Piloting Plan.

Study Guide reference: Release - > Ship Deliverables - > Organizational Deployment Methods/Piloting Plan.

========