Scrum SMC - Scrum Master Certified (SMC)

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.

========

For a large project involving multiple Scrum Teams, coordination is commonly achieved through a Scrum of Scrums (SoS) Meeting. SCRUMstudy states that this meeting is usually facilitated by the Chief Scrum Master, whose focus is coordination and integration across the participating Scrum Teams.

Representatives from each Scrum Team attend the SoS meeting. In many cases, the representative is the individual team's Scrum Master, although another technically knowledgeable team member may represent the team when appropriate. These representatives provide status information, identify inter-team impediments and dependencies, and disclose activities that could affect other teams.

The Chief Product Owner is concerned principally with coordinating product and business-value matters across multiple Product Owners, not with facilitating the Scrum of Scrums. Option D, “Scrum Master,” is less precise because the question describes the designated scaled-project facilitation role. Although another Scrum Master can sometimes facilitate an SoS, the defined role in the standard large-project structure is the Chief Scrum Master.

Therefore, B is the expected SMC answer.

Study Guide reference: Organization - > Scrum in Large Projects - > Chief Scrum Master; Scrum of Scrums Meeting.

========

A Risk Breakdown Structure (RBS) is specifically designed to organize identified risks into logical categories based on common characteristics or sources. SCRUMstudy describes an RBS as a technique in which risks are grouped according to categories or commonalities—for example, financial, technical, operational, safety, regulatory, or external risks. This hierarchical categorization makes a potentially large collection of risks easier to analyze and manage.

The other options serve different purposes. A Risk Checklist helps ensure that commonly encountered risks are not overlooked. A Risk Prompt List stimulates thinking about possible risk sources. Brainstorming generates potential risks through collaborative discussion among knowledgeable participants. None of those techniques is primarily intended to categorize and structure already identified risks according to similarities.

The wording “categorize and organize” is therefore decisive. Once risks have been identified, an RBS provides a structured view that facilitates further assessment, ownership, prioritization, and response planning.

Consequently, Risk Breakdown Structure is the appropriate technique.

Study Guide reference: Risk - > Risk Identification - > Risk Breakdown Structure; Risk Checklists; Risk Prompt Lists; Brainstorming.

========

Self-organization means that the Scrum Team determines how best to accomplish the work required to achieve the established project and Sprint objectives. Team members pull work, coordinate responsibilities, resolve problems collaboratively, and collectively produce tangible Sprint results.

Creating the Project Vision, however, is not a goal of the self-organizing Scrum Team. The Project Vision is established during the Initiate phase, principally under Product Owner leadership, before detailed Sprint execution. The vision provides direction within which the Scrum Core Team then self-organizes.

Option A reflects self-organized problem solving: Daily Standup identifies impediments, and detailed solutions are normally handled outside the short meeting. Option B is central to Sprint execution. Option D reflects Scrum's expectation that teams create tangible, potentially shippable results during iterations.

Self-organization therefore operates within an established vision rather than replacing the responsibility for defining that vision. The team decides how to achieve the objective but does not independently establish the project's overarching business purpose.

Consequently, C is not a goal of the self-organizing Scrum Team.

Study Guide reference: Principles - > Self-organization; Initiate - > Create Project Vision.

========

The technique described is Planning Poker. In Planning Poker, Scrum Team members receive decks containing numerical values, commonly based on a modified Fibonacci sequence. After discussing a User Story or task, every estimator independently selects a card representing the relative effort, size, or complexity of that item. The cards are then revealed, and differences in estimates trigger further discussion until sufficient consensus is achieved.

Fist of Five uses fingers rather than numbered card decks and is useful for estimation or rapid consensus-building. Wideband Delphi involves repeated independent estimates and discussion but does not inherently require Planning Poker cards. Affinity Estimation instead groups or orders items by relative size.

Planning Poker combines individual judgment with collaborative discussion. Simultaneous revelation also reduces anchoring because one participant's estimate cannot influence everyone else's initial estimate before they have committed to a value.

The explicit reference to a deck of numbered cards and each member selecting a card corresponding to an estimate makes Planning Poker unambiguous.

Study Guide reference: Plan and Estimate - > Estimate User Stories/Estimate Tasks - > Planning Poker; Relative Estimation.

========

The Product Owner defines the User Story Acceptance Criteria based on understanding of customer and business requirements, but once a User Story has been committed to an active Sprint, the Scrum Master is responsible for protecting the team from inappropriate mid-Sprint alteration of those criteria.

SCRUMstudy explicitly assigns the Scrum Master responsibility for ensuring that Acceptance Criteria are not changed by the Product Owner in the middle of the Sprint.

This preserves Sprint stability and prevents completed or partially completed work from being judged retrospectively against requirements that did not exist when the team made its commitment. New or changed requirements are normally reflected in the Prioritized Product Backlog and considered for a subsequent Sprint.

The Sponsor, customers, and users may supply feedback and business requirements, but they do not control the active Sprint's Acceptance Criteria. The Product Owner owns the criteria but is precisely the role whose mid-Sprint changes must be controlled.

Therefore, the Scrum Master ensures that the agreed Acceptance Criteria remain stable for the committed Sprint.

Study Guide reference: Quality - > User Story Acceptance Criteria; Change - > Maintaining Sprint Stability; Scrum Master responsibilities.

========

SBOK uses a standardized User Story structure that captures three fundamental dimensions of a requirement: Who, What, and Why. The prescribed format is:

As a < role/persona > , I should be able to < requirement > so that < benefit > .

The role/persona identifies the person or user group receiving value. The requirement identifies the capability needed. The benefit explains the business or user value produced by satisfying that requirement. Keeping this order helps ensure that the team does not treat a backlog item merely as a technical specification; instead, the requirement remains connected to the stakeholder who needs it and to the reason it creates value.

Options B, C, and D rearrange these components and therefore do not conform to the standard SBOK User Story template.

This structure also improves communication and estimation because Product Owners, Scrum Team members, and stakeholders can discuss the requirement in a compact, user-oriented format.

Study Guide reference: Plan and Estimate - > Create User Stories - > User Story Template; Personas; User Story Acceptance Criteria.

========

Time-boxing does not exist to avoid change. Scrum explicitly accepts that change is inevitable, particularly in complex projects where stakeholder understanding and market requirements evolve. Time-boxing provides controlled boundaries within which work remains stable, while allowing change to be incorporated at appropriate inspection and planning points.

SCRUMstudy defines time-boxing as allocating a fixed amount of time to an activity or process. It prevents unlimited expansion of tasks and supports disciplined management of uncertainty and deadlines.

For example, once a Sprint begins, its scope is protected so the Scrum Team can maintain focus. New requirements can still be incorporated into the Prioritized Product Backlog and prioritized for a subsequent Sprint. Therefore, time-boxing manages change rather than attempting to eliminate it.

It also limits exposure to uncertain work by forcing regular inspection of results and preventing indefinite analysis or development. Deadlines become visible and predictable because Scrum events and Sprints have bounded durations.

Thus, “using time-boxing as a medium to avoid changes” contradicts Scrum's adaptive philosophy and is the exception.

Study Guide reference: Principles - > Time-boxing; Change - > Flexibility and Stability.

========

The intended answer is Continuous stakeholder involvement because it is not one of the specific SBOK characteristics listed for achieving flexibility.

SCRUMstudy identifies the principal mechanisms supporting flexibility as iterative product development, time-boxing, cross-functional teams, customer value-based prioritization, and continuous integration. These mechanisms allow Scrum projects to absorb changing business needs while protecting stability within an active Sprint.

Iterative development creates repeated opportunities to inspect outcomes and adjust requirements. Time-boxing constrains uncertainty and establishes predictable review intervals. Cross-functional teams reduce handoffs and external dependencies by containing the required skills within the team.

Stakeholder involvement is certainly important in Scrum and supports feedback, validation, and value realization. However, the question asks for the item that is not part of the specific enumerated SBOK list of characteristics used to explain flexibility. The formally listed concept is customer value-based prioritization rather than “continuous stakeholder involvement.”

This is therefore a terminology-sensitive SMC question: option C describes a useful Scrum practice, but it is not the designated characteristic in this particular SBOK framework.

Study Guide reference: Change - > Flexibility versus Stability; Principles - > Iterative Development and Time-boxing.

========