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

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 Prioritized Product Backlog is not listed as an input to the SBOK Conduct Daily Standup process. In the relevant SBOK process model, inputs include the Scrum Team, Scrum Master, Scrumboard, Impediment Log, Sprint Burndown/Burnup Chart, Product Owner, previous workday experience, and dependencies. The Product Owner is not mandatory for the meeting, but may contribute as an input to the process.

The Sprint Burndown Chart provides visibility into Sprint progress and remaining work. Dependencies may surface during the Daily Standup because they can create impediments or affect sequencing. The Product Owner may be available where clarification or business input is relevant, although the Daily Standup remains principally a Scrum Team synchronization forum.

The Prioritized Product Backlog is instead the overarching project requirements repository managed and refined through backlog processes. The active Sprint is driven by its Sprint Backlog, not by repeatedly replanning directly from the entire Prioritized Product Backlog each day.

Therefore, among the options presented, B is the exception.

Study Guide reference: Implement - > Conduct Daily Standup - > Inputs; distinction between Prioritized Product Backlog and Sprint execution artifacts.

========

The Prioritized Product Backlog is not a tool of the Create Deliverables process. In the legacy SBOK process structure underlying this question, the principal Create Deliverables tools include Team Expertise, Software, Other Development Tools, and Scrum Guidance Body Expertise. Other Development Tools may include techniques such as refactoring and Design Patterns.

Team Expertise represents the collective technical and functional knowledge used by Scrum Team members to transform Sprint work into finished deliverables. Software tools may support scheduling, collaboration, tracking, information distribution, and project execution. Design Patterns provide reusable approaches for resolving recurring design problems and can therefore support creation of deliverables.

The Prioritized Product Backlog serves a different function: it represents the prioritized project requirements maintained by the Product Owner. During the Sprint itself, the Scrum Team executes work from the Sprint Backlog, which contains the committed work for that Sprint.

Therefore, although the Prioritized Product Backlog ultimately drives what enters future Sprints, it is not classified as a Create Deliverables tool.

Study Guide reference: Implement - > Create Deliverables - > Inputs and Tools.

========

Statements II, III, and IV align with the Scrum Master's facilitative role. The Scrum Master ensures Scrum practices and processes are correctly followed, supports transparency and effective communication, facilitates Scrum meetings, and removes obstacles that interfere with successful delivery. SCRUMstudy describes the Scrum Master as the facilitator and supporting/servant leader who creates an environment conducive to team success.

Statement I is incorrect because strategic objectives and priorities are not defined by the Scrum Master. Strategic priorities are associated with Product Owner roles at the appropriate organizational level—for example, Program Product Owner or Portfolio Product Owner when Scrum is scaled. The Scrum Master supports execution of Scrum and removes impediments; the role does not own the business strategy.

Release Planning is also facilitated or coordinated by the Scrum Master while the Product Owner and Scrum Team participate in determining the release structure and Sprint length. Transparency is supported through visible artifacts, effective facilitation, and adherence to empirical process control.

Therefore, the valid combination is II, III, and IV.

Study Guide reference: Organization - > Scrum Master Responsibilities; Initiate - > Conduct Release Planning; Principles - > Empirical Process Control/Transparency.

========

Statement B is inaccurate because SBOK risk management operates across project, program, and portfolio levels. A risk may originate at the program or portfolio level yet affect one or more projects. In such circumstances, information about that risk must be communicated to the affected Product Owner and Scrum Team, while the risk can continue to be managed at the level where it originated. Serious portfolio/program risks can even cause a project team to reconsider or re-plan Sprint work.

Scrum's iterative structure also reduces exposure by creating short feedback cycles. Problems become visible sooner than in long sequential delivery models, allowing corrective action before excessive investment accumulates. Risk information can be communicated through artifacts such as Risk Burndown Charts.

Scrum's flexibility further assists risk management because approved changes can be incorporated into the Prioritized Product Backlog and prioritized for subsequent Sprints. This does not mean uncontrolled scope changes are introduced into an active Sprint; Sprint stability remains protected.

Therefore, the assertion that risks can only be managed at project level directly contradicts SBOK's treatment of program- and portfolio-level risk.

Study Guide reference: Risk - > Risks in Portfolios and Programs; Risk Identification, Assessment, Prioritization, and Communication.

========

SBOK establishes a specific exception to the general rule that Sprint scope remains unchanged once implementation begins. If the Scrum Team determines that it has significantly overestimated the effort required and consequently has genuine spare capacity, the team may ask the Product Owner which additional User Stories can be introduced into the current Sprint.

The Sprint Backlog and Sprint Burndown/Burnup information can make this situation visible by showing that work is being completed considerably faster than expected and that meaningful capacity remains.

Option A is insufficient because having highly skilled individuals does not itself authorize scope modification. Option B is also insufficient: one idle member does not necessarily mean the overall Scrum Team has enough capacity to complete another User Story. Option C concerns potential future Change Requests and provides no justification for disturbing the current Sprint.

The exception therefore applies when the team as a whole has overestimated effort and has spare capacity. Even then, the Scrum Team does not unilaterally select new work; it asks the Product Owner which additional prioritized User Story should be included.

Study Guide reference: Change - > Changes to a Sprint - > Exception for Overestimated Effort and Spare Capacity.

========

Page

Scrum Master Certified (SMC®) — 100 Questions

A Gap Analysis is specifically used to compare the organization's current or actual state with a desired future state. SCRUMstudy defines it as identifying and documenting the difference between existing business capabilities and the final desired set of capabilities.

That wording directly matches the scenario.

A SWOT Analysis examines strengths, weaknesses, opportunities, and threats and is useful when establishing context, priorities, risks, and strategic direction. A Joint Application Development (JAD) session is a facilitated workshop used to gather and refine requirements through direct collaboration. A Trial Project may be used to test an approach, but it does not specifically quantify or document capability differences.

Gap Analysis helps decision-makers determine what capabilities are missing, where improvement is required, and therefore why a project or program may be needed. The results can contribute directly to development of the Project Vision and later business requirements.

Therefore, because the scenario asks for comparison between current capability and desired capability, Gap Analysis is unambiguous.

Study Guide reference: Initiate - > Create Project Vision - > Gap Analysis.

========

In the legacy SBOK Create Sprint Backlog process represented by this question, important inputs include the Effort Estimated Task List, Length of Sprint, Previous Sprint Velocity, Dependencies, and Team Calendar, together with the Scrum Core Team. Therefore, the four factors listed in option C are all legitimate inputs.

Length of Sprint defines the available time-box. Previous Sprint Velocity provides historical evidence of how much work the team has been able to complete and therefore supports realistic commitment. Dependencies influence the order in which work should be executed. The Team Calendar records member availability, including leave, holidays, and other events affecting capacity.

The remaining options introduce artifacts that do not constitute this specific combination of Sprint Backlog creation inputs, such as Proof of Concept or Done Criteria.

In newer SBOK editions, the terminology has evolved toward Update Sprint Backlog, because an initial Sprint Backlog is created when User Stories are committed and is subsequently enriched with task-level information. The underlying capacity concepts—Sprint length, dependencies, team availability, and historical performance—remain relevant.

Therefore, C is the verified legacy SMC answer.

Study Guide reference: Plan and Estimate - > Create/Update Sprint Backlog - > Inputs; Sprint Planning.

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 sustainable pace is a level of effort that the Scrum Team can maintain consistently without burnout, chronic overtime, deterioration in quality, or progressively declining effectiveness. Therefore, option C most accurately reflects the concept: Sprint effort should normally be comparable with previous Sprints and remain comfortable and repeatable for the team.

Sustainable pace does not mean continually increasing workload as experience grows. Productivity may improve as the team learns, but that improvement should arise from better collaboration, technical practices, reduced waste, and accumulated knowledge—not from continually demanding greater physical effort.

Likewise, sustainable pace does not imply that effort must steadily decrease. Different Sprint contents will vary, but the team's workload should remain within a manageable long-term capacity.

SCRUMstudy links sustainable pace directly to quality. Excessive overtime and end-loaded testing tend to increase defects and reduce maintainability, while regular development and testing throughout Sprints produce a more stable working environment.

Thus C expresses the central idea: consistent, repeatable, healthy effort across Sprints.

Study Guide reference: Quality - > Sustainable Pace; Scrum Master Responsibilities Relevant to Quality.

========