Pass the Scrum Scrum Master Certified SMC Questions and answers with CertsForce

A Probability Impact Grid evaluates each identified risk according to two primary dimensions: its probability of occurrence and its potential impact on project objectives. SBOK explains that each dimension may be assigned a numerical or categorical rating and that probability and impact can then be combined to derive a risk-severity score.

That makes the technique particularly appropriate for the flood-and-landslide scenario. The team can estimate how likely these events are and assess the severity of their consequences for safety, cost, schedule, infrastructure, or environmental objectives. The resulting score helps determine prioritization and the urgency of mitigation.

Probability Trees model multiple possible outcomes as branches and calculate associated expected values. Pareto Analysis ranks identified risks by magnitude to focus attention on the most significant contributors. Expected Monetary Value converts uncertainty into a financial expectation by multiplying monetary impact by probability.

All four can support risk analysis, but the question specifically emphasizes evaluating probability and impact on project objectives, which directly matches the Probability Impact Grid.

Study Guide reference: Risk - > Risk Assessment - > Probability Impact Grid.

========

Risk is explicitly one of the principal factors considered when constructing and prioritizing the Prioritized Product Backlog. SCRUMstudy identifies value, risk or uncertainty, and dependencies as three primary factors on which backlog prioritization is based.

Option A is therefore incorrect because dependencies may materially affect sequencing. One User Story may rely on functionality supplied by another, and such relationships must be considered during prioritization. SCRUMstudy also identifies splitting or combining stories as possible approaches for resolving dependencies.

Option B is too restrictive. Business value is important, but prioritization is not based only on subjective value. Risk, dependencies, business requirements, estimates, and other relevant considerations influence the ordering of work.

Option D is also incorrect because Scrum can use multiple prioritization techniques, including collaborative methods where appropriate. The framework does not establish a universal prohibition on voting.

Risk-aware prioritization allows high-risk or high-uncertainty work to be addressed early enough to expose problems and enable mitigation.

Study Guide reference: Business Justification - > Value-based Prioritization; Risk - > Risk-adjusted Prioritized Product Backlog.

========

Option A does not correctly represent Scrum collaboration because it assigns business prioritization authority to the Scrum Team. Determining which User Stories are most important is principally the Product Owner's responsibility through management of the Prioritized Product Backlog. The Scrum Team subsequently estimates, commits to, and determines how to implement the selected work.

Options B, C, and D are genuine examples of collaborative behavior. Discussing the best implementation approach represents joint problem solving by a self-organizing team. Helping another team member overcome task difficulty demonstrates collective ownership rather than rigid individual specialization. Interacting with the Product Owner for requirement clarification enables the Scrum Team to understand intended value and Acceptance Criteria.

SBOK defines collaboration around awareness, articulation, and appropriation, treating delivery as shared value creation among team members and stakeholders.

The Scrum Team participates heavily in planning and can influence what it can realistically commit to, but it does not take over Product Owner accountability for ranking User Stories according to business value.

Study Guide reference: Principles - > Collaboration; Organization - > Product Owner versus Scrum Team Responsibilities.

========

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.

========

The Release Planning Meeting is associated with the Initiate phase, specifically the Conduct Release Planning process. It is therefore not an Implement-phase activity.

SCRUMstudy identifies three Implement processes: Create Deliverables, Conduct Daily Standup, and Refine Prioritized Product Backlog. During Create Deliverables, the team executes Sprint Backlog tasks. Conduct Daily Standup provides daily synchronization and impediment identification. Refine Prioritized Product Backlog continually updates and maintains the project's backlog as new information, requirements, risks, and changes emerge.

Option B uses the wording “Updating the Product Backlog,” which corresponds to the refinement process and is therefore part of Implement. Option A directly represents Conduct Daily Standup, while D directly represents Create Deliverables.

Release Planning instead establishes the release schedule, planned delivery intervals, and Sprint length at the project-initiation level, though the schedule can later be updated as conditions evolve.

Consequently, C is the activity not executed as an Implement process.

Study Guide reference: Implement - > Create Deliverables, Conduct Daily Standup, Refine Prioritized Product Backlog; Initiate - > Conduct Release Planning.

========

The incorrect statement targeted by this question is statement II. A Scrumboard is fundamentally a Scrum Team information radiator used to visualize and track Sprint work. SCRUMstudy explains that the team uses the Scrumboard to plan and track progress and that it can be maintained manually on paper or a whiteboard, or electronically.

Stakeholders may be able to observe the board because Scrum promotes transparency, but the board is not described as a stakeholder-owned planning and progress-control mechanism. Sprint execution remains with the self-organizing Scrum Team.

The exact number of columns has varied across SBOK editions and examples. Typical layouts include To Do, In Progress, Testing, and Done; other representations may include an additional Stories column. Therefore, the essential exam concept is not a rigid visual format but the board's role in transparently showing Sprint task status. During implementation it is continually updated as work progresses, and a fresh board is used for the subsequent Sprint.

Thus statement II incorrectly assigns ownership/use to stakeholders rather than the Scrum Team.

Study Guide reference: Implement - > Create Deliverables - > Scrumboard; Empirical Process Control - > Transparency.

========

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.

========

The Scrum Master should be selected based on characteristics such as problem-solving ability, availability, commitment, facilitation capability, and a supporting/servant leadership style. SCRUMstudy specifically identifies availability for meetings, skills for removing impediments, and commitment to maintaining a conducive work environment as relevant selection criteria.

Option D violates Scrum's principle of self-organization. The Scrum Master does not make technical implementation decisions on behalf of the Scrum Team. The Scrum Team has the authority and responsibility to determine how Prioritized Product Backlog Items are converted into finished deliverables. The Scrum Master's function is to facilitate, coach, protect the process, and remove obstacles—not to act as a technical project manager.

This distinction is fundamental. If the Scrum Master dictated technical decisions, responsibility would shift away from the self-organizing, cross-functional team and recreate a command-and-control structure inconsistent with Scrum.

Therefore, technical decision-making authority on behalf of the Scrum Team is not an appropriate Scrum Master selection criterion.

Study Guide reference: Organization - > Identify Scrum Master and Business Stakeholder(s) - > Selection Criteria; Scrum Team - > Self-organization and technical authority.

========

Sprint length should be selected deliberately and consistently, with consideration for the nature of the project, anticipated rate of change, risk, and planned release dates. SCRUMstudy specifically identifies planned product or service release dates as a factor that should be considered when determining Sprint length.

Option B is incorrect because the expected frequency and impact of changes matter considerably. Environments with substantial uncertainty or frequent changes often benefit from shorter feedback cycles, allowing the team and Product Owner to inspect results and adapt more frequently.

Option C reverses the logic. A highly stable environment does not automatically require the shortest Sprint purely because little change is expected. Sprint length should reflect the project's context rather than follow that blanket rule.

Option D is also incorrect. SBOK guidance uses relatively short Sprint intervals and emphasizes consistent time-boxes. A universal six-week Sprint is not the recommended rule.

Once an appropriate Sprint length has been agreed upon, unnecessary variation between Sprints should be avoided because changing duration undermines historical velocity and forecasting comparability.

Study Guide reference: Initiate - > Conduct Release Planning - > Length of Sprint; Principles - > Time-boxing and Iterative Development.

========

The Skills Requirement Matrix, also described as a competency framework, is specifically intended to map the competencies available within a team and identify development needs. SCRUMstudy's SBOK glossary states that this matrix is used to assess skill gaps and training requirements while mapping team members' skills, capabilities, and interest in applying those capabilities to the project.

This makes option A an exact match to the scenario.

An Organizational Deployment Method concerns how a release or organizational change may be introduced and does not map individual competencies. A Daily Standup enables coordination, status synchronization, and identification of impediments, but it is not a formal competency-assessment tool. “Organizational Resource Matrix” is not the SBOK tool defined for the detailed skills analysis described.

A Skills Requirement Matrix can therefore help identify whether sufficient expertise exists to satisfy project needs, where cross-training may be appropriate, and which team members require additional training. It also assists during team formation and capability planning.

Study Guide reference: Organization - > Form Scrum Team - > Skills Requirement Matrix/Competency Framework; Team capability and training requirements.

========