Free Scrum SMC Practice Exam with Questions & Answers | Set: 2

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.

========

Create Sprint Backlog belongs to the Plan and Estimate phase, not the Implement phase.

In the terminology of this question's SBOK edition, the Implement phase consists of:

- Create Deliverables

- Conduct Daily Standup

- Groom Prioritized Product Backlog

Current SCRUMstudy terminology renames the third process Refine Prioritized Product Backlog, but it remains part of Implement.

Sprint Backlog creation occurs during planning after User Stories have been estimated and committed and tasks have been identified and estimated. The Sprint Backlog represents the work selected and structured for execution during the forthcoming Sprint.

Once implementation begins, the Scrum Team works through Sprint Backlog tasks to create deliverables, synchronizes through Daily Standups, and maintains the overall Prioritized Product Backlog through refinement activities.

Therefore, Create Sprint Backlog is the only listed process outside the Implement phase.

Study Guide reference: Plan and Estimate - > Create/Update Sprint Backlog; Implement - > Create Deliverables, Conduct Daily Standup, Groom/Refine Prioritized Product Backlog.

========

The Create Deliverables process is an Implement-phase activity in which the Scrum Team executes the tasks contained in the Sprint Backlog and creates the Sprint Deliverables. SCRUMstudy describes this process as the team working on Sprint Backlog tasks to produce deliverables while using mechanisms such as the Scrumboard and Impediment Log to manage execution.

Options A, C, and D can represent tangible or project-specific results produced through Sprint execution. Construction work, an updated engineering blueprint, and completed seismic retrofit work can each constitute deliverables when they correspond to committed Sprint Backlog items and satisfy the applicable Done Criteria.

Raw materials acquired for the next Sprint, however, represent preparation or resource procurement for future work rather than a deliverable generated from execution of the current Sprint Backlog. The defining output of Create Deliverables is completed work resulting from the current Sprint's committed tasks, not inventory accumulated for subsequent iterations.

Therefore, B is the exception.

Study Guide reference: Implement - > Create Deliverables - > Sprint Backlog execution, Sprint Deliverables, Scrumboard, Impediment Log.

========

Mark should inform the Scrum Master, who can address the resource interference with the Product Owner. One of the Scrum Master's fundamental responsibilities is to maintain an environment conducive to team success and remove impediments or organizational interference that threatens Sprint execution.

Option A is incorrect because Sprint deadlines are not simply extended when resource problems occur. The Sprint is a fixed time-box. Option B is also inconsistent with self-organization because the Scrum Master should not act as a traditional manager by directly assigning Mark's task to another team member. The Scrum Team determines internally how work is allocated.

Option D incorrectly assumes that the Product Owner can automatically move unfinished work while disrupting the active Sprint. If work cannot be completed, backlog consequences are handled through the normal Sprint and backlog processes rather than by arbitrarily extending or reallocating committed work.

A mid-Sprint reassignment can undermine capacity, predictability, and Sprint commitment. The Scrum Master should therefore raise the issue with Andy and protect the team's ability to perform its committed work while facilitating an appropriate organizational resolution.

Study Guide reference: Organization - > Scrum Master as Facilitator/Supporting Leader; Self-organization; Impediment Removal.

========

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

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 Scrum Master facilitates the identification, assessment, communication, and escalation of problems and Change Requests generated by the Scrum Team. The Product Owner then evaluates business impact and determines how approved changes should be prioritized within the Prioritized Product Backlog. This separation preserves both facilitation and business accountability.

Option A is contrary to Scrum. Scrum does not attempt to eliminate change; it deliberately accommodates change while maintaining stability during the active Sprint.

Option C is primarily a Product Owner/business stakeholder responsibility when interpreted as formally submitting project changes. Scrum Team members and the Scrum Master may suggest improvements, but the Scrum Master's principal defined change-management responsibility is facilitation, not ownership of business Change Requests.

Option D incorrectly gives approval authority to the Scrum Master. Formal change approval and prioritization are driven by the Product Owner within organizational tolerance levels and applicable Scrum Guidance Body procedures.

Consequently, B accurately reflects the Scrum Master's servant-leadership role: enabling the Scrum Team to surface necessary changes and ensuring that those changes reach the appropriate Product Owner decision process.

Study Guide reference: Change - > Summary of Responsibilities Relevant to Change; Change Requests; Product Owner prioritization.

========

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.

========

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.

========

A Scrumboard represents work associated with a particular Sprint. During that Sprint, tasks move through workflow states such as To Do, In Progress, Testing, and Done. The board is updated continuously so that the team has a transparent view of current progress.

At the completion of the Sprint, however, that Sprint's working board is no longer the active execution board. Earlier SBOK guidance explicitly describes the Scrumboard as being reset or wiped off, with a new Scrumboard created for the next Sprint. Current SBOK guidance similarly states that one Scrumboard is valid for one Sprint and that the Scrum Team creates a new board for the next Sprint.

This distinction is important because velocity is not calculated merely by retaining two physical boards side by side. Historical metrics and Sprint results can be preserved through appropriate tracking mechanisms, while the operational Scrumboard remains focused on current Sprint work.

Thus the exam wording “reset or wiped off” reflects the SBOK concept that each Sprint receives its own current execution view rather than indefinitely accumulating tasks from earlier Sprints.

Study Guide reference: Implement - > Create Deliverables - > Updated Scrumboard; Scrumboard lifecycle across Sprints.

========