Pass the Scrum Master Certified SMC Questions and answers with Dumpstech

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.

========

The description corresponds to the Scrum Guidance Body (SGB). The SGB can provide organizational guidance, standards, regulations, recommended practices, templates, procedures, and lessons learned that Scrum Core Teams may use when appropriate.

In the backlog-refinement context, Scrum Guidance Body Recommendations can include guidance on how to understand and collate requirements, prioritize the backlog, document User Stories appropriately, and communicate changes to relevant participants.

Subject Matter Experts provide specialized knowledge based on particular technical or business domains, but the question specifically refers to documented organizational rules, development guidelines, standards, and best practices, which are characteristic of the Scrum Guidance Body.

Team Expertise refers to the collective capability of Scrum Team members to understand and execute Sprint work. Stakeholders contribute requirements, business needs, feedback, and priorities, but they are not the repository responsible for organizational Scrum standards.

The Scrum Guidance Body therefore provides consistency without converting Scrum into a centralized command-and-control methodology. Its recommendations support teams while still allowing appropriate tailoring.

Study Guide reference: Implement - > Groom/Refine Prioritized Product Backlog - > Scrum Guidance Body Recommendations.

========

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.

========

Scrum balances flexibility with Sprint-level stability. Once the team commits to Sprint work, outside interference and arbitrary requirement changes should be prevented so that the Scrum Team can maintain focus and produce the committed increment.

The Scrum Master helps protect the Scrum Team from disruption, while the Scrum Team maintains commitment to the Sprint work. New Change Requests generally enter the Prioritized Product Backlog and are evaluated and prioritized for a future Sprint rather than being inserted indiscriminately into the active Sprint.

Option B violates this stability principle by suggesting that a Sponsor should introduce and approve changes directly during the Sprint. Option C is incorrect because Scrum does not seek “complete stability” across the project; the overall project remains deliberately adaptive. Option D is too absolute. Change approval authority can vary according to organizational tolerances and program/portfolio governance, even though the Product Owner controls project backlog prioritization.

Scrum's objective is therefore stable execution inside the Sprint and flexibility between Sprints, not resistance to change throughout the project.

Study Guide reference: Change - > Balancing Flexibility and Stability; Maintaining Sprint Stability.

========

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.

========

SBOK distinguishes risks from issues primarily through uncertainty. A risk is an uncertain future event that may affect project objectives. An issue is an existing, well-defined condition that is already occurring and therefore does not require a probability assessment.

Statements I and II contain future uncertainty: the representatives might not be ready, and the painting crew might be delayed by rain. These events have not occurred and therefore qualify as risks.

Statements III and IV describe current facts. Funding was not approved, making this an existing problem. Requirements are unclear, so ambiguity is already affecting the project. SCRUMstudy actually uses these examples when explaining the distinction: delayed crews and potentially unprepared representatives are risks, while unapproved funding and unclear requirements are issues.

Risk management is proactive—identify, assess, prioritize, mitigate, and communicate uncertain events before they materialize. Issues require active resolution because they are already real.

Therefore, I and II are the risks.

Study Guide reference: Risk - > Difference between Risks and Issues.

========

The technique described is Expected Monetary Value (EMV). EMV translates an uncertain event into a monetary risk exposure by multiplying its probability of occurrence by its financial impact.

For the scenario:

EMV = Probability × Monetary Impact

EMV = 0.45 × (-$800,000) = -$360,000

The negative sign represents an expected loss. Thus, the risk contributes an expected monetary exposure of $360,000 to the economic analysis of the project. EMV is particularly useful when comparing uncertain alternatives or integrating risk into business-justification calculations.

A Probability Impact Grid classifies risks according to probability and impact, typically for prioritization; it does not primarily calculate monetary expectation. Pareto Analysis identifies the relatively small number of causes responsible for the largest proportion of effects. A Risk Breakdown Structure categorizes risks hierarchically according to source or similarity.

Because the question explicitly supplies both a percentage probability and a monetary loss, EMV is the technique being applied.

Study Guide reference: Business Justification/Risk - > Risk Assessment Techniques - > Expected Monetary Value; financial analysis of uncertainty.

========

Done Criteria establish the common quality conditions that apply across User Stories and provide a consistent basis for determining whether work is complete. The SBOK framework identifies activities such as completed unit testing, completed documentation, quality-assurance activities, peer review, resolution of issues, and successful demonstrations as legitimate examples of Done Criteria.

The critical distinction in this question is statement I. A list of issues to be fixed means unresolved work remains. That is different from the SBOK concept that all relevant issues are fixed before the item satisfies the Done Criteria. Therefore, simply maintaining a list of outstanding problems cannot itself establish completion.

Unit testing is directly associated with confirming technical quality. Documentation may be required to satisfy organizational, regulatory, operational, or support requirements. Demonstration to stakeholders or business representatives can also form part of the general completion conditions established for the project. Consequently, statements II, III, and IV are appropriate, while statement I is not properly worded as a completion condition.

Study Guide reference: Quality - > Done Criteria; Create Prioritized Product Backlog - > establishment of Done Criteria; distinction between Done Criteria and User Story Acceptance Criteria.

========

Option C is false because User Story Acceptance Criteria are primarily defined by the Product Owner, based on the Product Owner's understanding of customer and business requirements. The Product Owner then communicates the User Stories and their criteria to the Scrum Team, and agreement and clarification are obtained. SCRUMstudy explicitly identifies Acceptance Criteria as objective conditions developed by the Product Owner.

The Scrum Master facilitates the process and ensures that agreed Acceptance Criteria are not inappropriately changed during an active Sprint, but the Scrum Master does not jointly own their definition with the Scrum Team.

Option D accurately reflects Scrum's iterative delivery approach: work is developed in short, time-boxed Sprints. Options A and B describe the more centralized quality and formal change-management characteristics typically associated with traditional project-management models in the SBOK comparison.

This distinction is important because Scrum incorporates quality continuously through Done Criteria, Acceptance Criteria, iterative development, inspection, adaptation, and frequent stakeholder feedback instead of treating quality primarily as a late project-control activity.

Study Guide reference: Quality - > Quality in Scrum versus Traditional Project Management; Acceptance Criteria; Product Owner Responsibilities.

========

Page

Scrum Master Certified (SMC®) — 100 Questions

An Epic represents a high-level requirement that is generally too large or insufficiently detailed to be completed as a single User Story within one Sprint. As an Epic rises in priority and approaches implementation, it is progressively elaborated and decomposed into smaller User Stories.

SCRUMstudy explicitly states that some Epics/User Stories are initially too large to handle within one Sprint and are therefore broken into smaller User Stories when they move high enough in the Prioritized Product Backlog to be considered for upcoming Sprint work.

Smaller User Stories improve estimation, clarification, testability, and the team's ability to create potentially shippable increments within the Sprint time-box. They also enable the Product Owner to prioritize individual pieces of functionality according to value rather than treating a large requirement as one indivisible block.

Option A may be an indirect benefit but is not the fundamental reason. Team size does not determine whether an Epic must be decomposed, and review duration is not the defining criterion.

Therefore, the correct answer is that Epics are too large to be completed within a single Sprint.

Study Guide reference: Plan and Estimate - > Create User Stories - > Decomposition of Epics.

========