Free Practice Questions for Scrum SMC Exam

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

Within the SBOK quality framework, the Scrum Master is responsible for facilitating a quality-oriented environment, eliminating environmental impediments, maintaining a sustainable pace, and ensuring that Scrum processes are correctly followed by all members, including the Product Owner. Therefore, option C directly corresponds to the Scrum Master's defined quality responsibilities.

Option A belongs primarily to the Product Owner. During Demonstrate and Validate Sprint, the Product Owner evaluates completed work against the User Story Acceptance Criteria and accepts or rejects the relevant User Stories or deliverables. Option B is associated with the Scrum Guidance Body, which may establish organizational standards, quality guidance, and the acceptable range of tools or practices. Option D belongs to the Scrum Team, which performs the development work and makes the technical changes necessary to create compliant deliverables.

This division of accountability is central to SMC role questions. The Scrum Master facilitates and protects the process but does not act as a conventional project manager or technical supervisor. The Product Owner protects value and acceptance, while the Scrum Team determines how the work is executed.

Study Guide reference: Quality - > Summary of Responsibilities Relevant to Quality; Organization - > Scrum Master role.

========

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.

========

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.

========

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.

========

After development is completed, the increment must be validated and demonstrated. The Scrum Team is responsible for ensuring that Sprint Deliverables satisfy the agreed quality conditions before presenting them in the Sprint Review/Demonstrate and Validate Sprint process. During that review, the team demonstrates completed functionality to the Product Owner and relevant business stakeholders, including customers or users where appropriate.

Acceptance Criteria provide the objective basis for checking whether a User Story satisfies the required functionality. Formal acceptance or rejection authority belongs to the Product Owner, not the Scrum Master.

Consequently, statement II is incorrect: the Scrum Master does not independently deploy the functionality into production merely because Sprint development has finished. Release is a business decision and follows the appropriate Ship Deliverables process. Statement IV is also incorrect because the Scrum Master cannot reject a User Story based on stakeholder feedback.

Statements I and III correctly represent demonstration and validation activities associated with completed Sprint work. Therefore, A is the intended answer.

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

========

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.

========

SBOK deliberately defines Scrum as broadly applicable. SCRUMstudy states that Scrum can be applied to portfolios, programs, and projects in any industry; to products and services; and to projects of varying sizes and complexity.

Each scenario therefore represents a condition Scrum can accommodate. Existing products receiving incremental updates can use Sprints to prioritize and release new value. Innovative products with uncertain outcomes particularly benefit from iterative development, frequent inspection, feedback, and adaptation. Scarce specialist skills can be addressed as shared-resource and organizational constraints, although careful capacity management is required. Distributed teams introduce communication and coordination challenges, but geographical distribution does not make Scrum inapplicable.

The question is testing an important principle: constraints influence how Scrum is implemented, rather than automatically disqualifying a project from Scrum. The framework can be scaled or organizational practices adapted to accommodate these conditions.

Accordingly, all four project scenarios can be candidates for Scrum, making D the intended SBOK answer.

Study Guide reference: Introduction to Scrum - > Applicability of Scrum; Organization - > Distributed Teams/Shared Resources; Principles - > Iterative Development.

========

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.

========

A Program Scrum Master extends the facilitative Scrum Master role from an individual project to the program level. SCRUMstudy describes the Program Scrum Master as responsible for guiding, facilitating, and teaching Scrum practices to those involved in the program; helping remove program-level impediments; supporting individual project Scrum Masters; and ensuring that Scrum processes are followed effectively.

Option B is associated more closely with the Program Product Owner, who establishes strategic objectives and priorities for the program and ensures alignment of component projects with program outcomes.

Option A improperly assigns ownership of business justification and viability creation to the Program Scrum Master. Business justification is primarily a Product Owner/business responsibility, although the Scrum Master may facilitate relevant processes.

Option D is inconsistent with Scrum because the Program Scrum Master does not directly control project teams. Scrum Masters facilitate self-organizing teams rather than exercising command authority over them.

Thus the correct responsibility is facilitating and teaching Scrum practices throughout the program.

Study Guide reference: Organization - > Scrum in Programs and Portfolios - > Program Scrum Master responsibilities; Supporting Leadership.

========