Scrum SMC - Scrum Master Certified (SMC)

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.

========

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.

========

Option A most accurately reflects the Product Owner's authority during backlog refinement and change management. The Product Owner decides which stakeholder input is relevant, evaluates suggested changes, and determines which changes should progress as formal Change Requests or be incorporated into the Prioritized Product Backlog.

Option B is incorrectly worded. The Scrum Master protects committed Sprint requirements and Acceptance Criteria throughout the active Sprint, not merely during the Sprint Review Meeting. The distinction matters because the Sprint Review occurs at the end of the Sprint and is specifically intended to validate completed deliverables and obtain feedback.

Option C describes development work that belongs to the Scrum Team. Stakeholders provide requirements, feedback, and Change Requests; they do not directly incorporate features into Sprint Deliverables.

Option D improperly gives the Scrum Team unilateral business authority over an urgent requirement change. Significant business changes are evaluated through the Product Owner/change-management mechanism. If a change is critical enough to invalidate current Sprint work, the Sprint can be terminated and replanned through the applicable Scrum governance process.

Therefore, A is the correctly matched responsibility.

Study Guide reference: Change - > Integrating Change; Product Owner Responsibilities; Groom/Refine Prioritized Product Backlog.

========

Acceptance Criteria are the objective conditions by which the functionality of a User Story is judged. They enable the Product Owner to determine whether the completed deliverable satisfies the agreed requirement and whether the associated User Story can be accepted as Done. SCRUMstudy specifically emphasizes the objectivity of Acceptance Criteria and the Product Owner's authority to accept or reject work against them.

Option C is incorrect because Acceptance Criteria are defined primarily by the Product Owner, based on understanding of customer requirements. The Scrum Master facilitates Scrum and protects the integrity of the Sprint but does not own those business acceptance conditions.

Option D places acceptance in the wrong meeting. Acceptance occurs during Demonstrate and Validate Sprint/Sprint Review, not during Retrospect Sprint. The retrospective concerns lessons learned and process improvement.

Option A similarly confuses activities and meetings.

Therefore, the core purpose of Acceptance Criteria is to provide measurable, objective conditions against which a User Story can be judged Done or not Done.

Study Guide reference: Quality - > Acceptance Criteria; Review and Retrospect - > Demonstrate and Validate Sprint.

========

C is the intended answer in the legacy SMC question bank, but the wording is technically defective because of the word “only.” Older SMC practice material keys C because SBOK historically described approximately 6–10 members as the ideal Scrum Team size. The intended concept is therefore that a typical individual Scrum Team should remain relatively small.

However, this must not be interpreted to mean Scrum itself can only be used when an entire project contains 6–10 people. Current SCRUMstudy guidance explicitly states that Scrum can be applied to projects of any size or complexity and can scale to large projects containing many Scrum Teams.

Options A, B, and D are clearly false: Scrum is not restricted to small projects, software development, or large corporations.

Thus, for the historical SMC item, C is the expected exam answer, but the accurate SBOK interpretation is: a Scrum Team is ideally small; Scrum as a framework is not limited to projects having only 6–10 total participants.

Study Guide reference: Introduction to Scrum - > Applicability of Scrum; Organization - > Scrum Team Size and Scaling.

========

Statements II and III are incorrect.

Rejected Deliverables are not normally maintained in a separate list. If a deliverable fails the Acceptance Criteria, the associated backlog work remains unresolved and is returned or retained in the Prioritized Product Backlog so that the Product Owner can reprioritize it for future development. SCRUMstudy explicitly states that rejected deliverables normally remain in the backlog rather than being placed in a separate repository.

Statement III also contradicts backlog refinement. The purpose of Groom/Refine Prioritized Product Backlog is to maintain a relevant, current, prioritized set of requirements. Items may be added, modified, reprioritized, refined, or removed when they cease to contribute sufficient business value or become obsolete.

Statement I is valid because backlog refinement can involve the Product Owner, Scrum Master, Scrum Team, and relevant stakeholders across multiple review interactions. Statement IV is also conceptually valid: changes in internal or external business conditions can generate changes at program level that subsequently affect project backlogs.

Current SCRUMstudy terminology uses Refine Prioritized Product Backlog, replacing the older term “Groom.”

Study Guide reference: Implement - > Groom/Refine Prioritized Product Backlog; Rejected Deliverables; Prioritized Product Backlog Review Meeting.

========

Identified Risks are not listed as an input to the Create User Stories process in the SBOK process model corresponding to this question.

The legacy SBOK Create User Stories inputs include the Scrum Core Team, Prioritized Product Backlog, Done Criteria, Personas, stakeholders, Epics, Business Requirements, applicable laws and contracts, and Scrum Guidance Body recommendations. The newer SBOK structure similarly retains the Prioritized Product Backlog, Done Criteria, Personas, and related requirement inputs.

The Prioritized Product Backlog provides the prioritized requirements from which detailed User Stories are elaborated. Personas help the Product Owner frame requirements from the perspective of representative users. Done Criteria establish common completion requirements applicable across User Stories.

Identified Risks certainly affect Scrum planning and backlog prioritization and are inputs to several other processes, but they are not formally included in the Create User Stories input list for the edition represented by this question.

Therefore, Identified Risks is the exception.

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

========

The Scrum Master facilitates planning rather than performing the team's estimates. Consequently, acting as the moderator and impediment remover is the correct responsibility.

During task estimation, the Scrum Team determines the effort necessary to accomplish tasks associated with committed User Stories. The resulting Effort Estimated Task List provides the estimated work associated with Sprint tasks and supports creation or updating of the Sprint Backlog. SCRUMstudy confirms that task estimation is performed by the Scrum Team and that the Scrum Master supports and facilitates the relevant meetings rather than imposing estimates.

Option B is not the objective of Scrum Master facilitation; diverse perspectives can naturally emerge, but they are not something the Scrum Master artificially ensures. Option C incorrectly suggests that the Scrum Master determines how tasks should be decomposed or estimated. That authority rests with the self-organizing Scrum Team. Option D is logically defective and reflects an obvious wording problem in the supplied question.

The Scrum Master therefore enables effective planning by maintaining the process, facilitating discussion, removing obstacles, and ensuring that the team—not the facilitator—owns the estimates.

Study Guide reference: Plan and Estimate - > Estimate Tasks - > Effort Estimated Task List; Sprint Planning Meeting; Scrum Master facilitation.

========

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 Daily Standup is a highly focused, time-boxed synchronization meeting for Scrum Team members. Members normally communicate what they completed, what they intend to do next, and what impediments are affecting their work. Every team member's participation supports transparency, coordination, collective ownership, and self-organization.

Option B directly conflicts with these principles. Inexperience does not justify excluding Scrum Team members. Less-experienced participants need visibility into the team's work just as much as experienced members and may require collaboration or assistance from colleagues. Exclusion would reduce transparency and weaken the team's collective responsibility.

Option A corresponds to discussing planned work. Option C corresponds to reporting progress since the previous meeting. Option D identifies an external environmental impediment—the distracting noise—which is appropriate to surface. The Daily Standup is not intended to become a lengthy problem-solving session, but impediments should be identified there and addressed subsequently, often with Scrum Master facilitation.

The Scrum Master therefore should reject the proposition that particular Scrum Team members need not attend merely because colleagues consider them inexperienced.

Study Guide reference: Implement - > Conduct Daily Standup; Organization - > Self-organizing Scrum Team; Scrum Master - > Impediment removal.

========