SMC Scrum Master Certified (SMC) Questions and Answers

Self-organization means that the Scrum Team determines how best to accomplish the work required to achieve the established project and Sprint objectives. Team members pull work, coordinate responsibilities, resolve problems collaboratively, and collectively produce tangible Sprint results.

Creating the Project Vision, however, is not a goal of the self-organizing Scrum Team. The Project Vision is established during the Initiate phase, principally under Product Owner leadership, before detailed Sprint execution. The vision provides direction within which the Scrum Core Team then self-organizes.

Option A reflects self-organized problem solving: Daily Standup identifies impediments, and detailed solutions are normally handled outside the short meeting. Option B is central to Sprint execution. Option D reflects Scrum's expectation that teams create tangible, potentially shippable results during iterations.

Self-organization therefore operates within an established vision rather than replacing the responsibility for defining that vision. The team decides how to achieve the objective but does not independently establish the project's overarching business purpose.

Consequently, C is not a goal of the self-organizing Scrum Team.

Study Guide reference: Principles - > Self-organization; Initiate - > Create Project Vision.

========

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.

========

Statement B is false because task creation, decomposition, estimation, and execution belong fundamentally to the Scrum Team, not to the Product Owner.

SCRUMstudy states that the Task List contains tasks associated with the committed User Stories and that it must include relevant testing and integration work. The level of decomposition or granularity is also determined by the Scrum Team.

Testing and integration are necessary because the increment created during the current Sprint must integrate successfully with deliverables produced in earlier Sprints. This makes statements A and C valid.

Statement D is likewise consistent with self-organization. Those performing the work are best positioned to determine how a User Story should be decomposed technically and how much detail is required for effective execution.

The Product Owner clarifies requirements and Acceptance Criteria but does not assign or commit individual implementation tasks on behalf of team members. During Sprint Planning, the self-organizing Scrum Team determines how to accomplish committed User Stories.

Therefore, B incorrectly transfers task commitment authority to the Product Owner.

Study Guide reference: Plan and Estimate - > Identify/Create Tasks; Estimate Tasks - > Task List and Team Ownership.

========

The Daily Standup is a synchronization and transparency mechanism, not an individual performance-management meeting. Team members discuss recent progress, upcoming work, and impediments so that the self-organizing Scrum Team can coordinate effectively and identify problems requiring follow-up.

SCRUMstudy describes Daily Standups as providing team members with visibility into strengths, weaknesses, missed tasks, dependencies, and impediments so that the team can collaboratively adjust its work.

Detailed problem solving is normally kept outside the tightly time-boxed meeting. An impediment raised during the Standup can subsequently be investigated and resolved with Scrum Master support. Information about recurring difficulties can also contribute to subsequent Sprint improvement discussions and retrospective learning.

Using the meeting to track individual employee performance, however, would undermine self-organization and encourage reporting upward to a manager rather than communication among peers. Scrum evaluates progress primarily at the team and deliverable level.

Therefore, individual performance tracking is specifically the inappropriate use of Daily Standup information.

Study Guide reference: Implement - > Conduct Daily Standup; Principles - > Self-organization and Collaboration.

========

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.

========

Option B is incorrect because responsibility for communicating and clarifying prioritized User Stories fundamentally rests with the Product Owner, not with the Scrum Master. SCRUMstudy states that Acceptance Criteria are developed by the Product Owner according to the Product Owner's understanding of customer requirements, after which the Product Owner communicates the User Stories to Scrum Team members and seeks their agreement.

The Scrum Master facilitates the process and helps ensure effective collaboration, but does not replace the Product Owner as the Voice of the Customer or primary source of business-requirement clarification.

Option A is therefore correct: the Product Owner develops Acceptance Criteria using customer requirements. Option C is also correct because the Scrum Team's agreement is sought when User Stories are communicated and prepared for Sprint work.

Option D reflects the acceptance mechanism: at Sprint review/validation, the Product Owner verifies completed work against the agreed Acceptance Criteria. When the deliverable satisfies the relevant criteria and is accepted, the associated User Story is considered Done.

Study Guide reference: Plan and Estimate - > Create User Stories/Acceptance Criteria; Quality - > Acceptance and Done; Product Owner responsibilities.

========

Page

Scrum Master Certified (SMC®) — 100 Questions

A Sprint Burndown Chart graphically represents the amount of work that remains to be completed during an ongoing Sprint. SCRUMstudy's SBOK glossary explicitly defines it as a graph depicting the amount of work remaining in the Sprint.

Normally, the horizontal axis represents elapsed Sprint time and the vertical axis represents remaining effort, tasks, or points. As work is completed, the plotted remaining workload should trend downward toward zero. Comparing actual remaining work with an expected trajectory helps the Scrum Team identify whether progress is broadly consistent with the Sprint plan.

Option A relates more directly to the Impediment Log and Daily Standup discussions. Although a Burndown Chart may indirectly indicate that progress has slowed, it does not identify the specific impediment causing that condition. Option C describes completed work rather than the traditional burndown representation of remaining work. Option D describes task or User Story estimation rather than Sprint tracking.

Therefore, its fundamental purpose is to visualize work remaining during the Sprint.

Study Guide reference: Implement - > Sprint Tracking Tools - > Sprint Burndown Chart.

========

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.

========

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 intended answer is Continuous stakeholder involvement because it is not one of the specific SBOK characteristics listed for achieving flexibility.

SCRUMstudy identifies the principal mechanisms supporting flexibility as iterative product development, time-boxing, cross-functional teams, customer value-based prioritization, and continuous integration. These mechanisms allow Scrum projects to absorb changing business needs while protecting stability within an active Sprint.

Iterative development creates repeated opportunities to inspect outcomes and adjust requirements. Time-boxing constrains uncertainty and establishes predictable review intervals. Cross-functional teams reduce handoffs and external dependencies by containing the required skills within the team.

Stakeholder involvement is certainly important in Scrum and supports feedback, validation, and value realization. However, the question asks for the item that is not part of the specific enumerated SBOK list of characteristics used to explain flexibility. The formally listed concept is customer value-based prioritization rather than “continuous stakeholder involvement.”

This is therefore a terminology-sensitive SMC question: option C describes a useful Scrum practice, but it is not the designated characteristic in this particular SBOK framework.

Study Guide reference: Change - > Flexibility versus Stability; Principles - > Iterative Development and Time-boxing.

========

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.

========

A deliverable does not become Accepted merely because the Scrum Team believes development is complete. Formal acceptance occurs when the Product Owner evaluates the deliverable against the agreed User Story Acceptance Criteria and accepts the associated User Story.

SCRUMstudy states that Acceptance Criteria are objective conditions used to judge User Story functionality. At the end of a Sprint, the Product Owner uses those criteria to verify completed deliverables and either accepts or rejects them. When accepted, the corresponding User Story is considered Done.

Option A lacks Product Owner validation. Option C reflects a team's assessment that work may be potentially shippable, but that does not independently constitute formal acceptance. Option D addresses internal testing and quality verification, which are necessary components of producing Done work but are insufficient by themselves to create an Accepted Deliverable.

This distinction separates technical completion from business acceptance. The Scrum Team builds and verifies the increment; the Product Owner determines whether the agreed business conditions have been fulfilled.

Therefore, B provides the correct definition.

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

========

C is the intended answer in the legacy SMC question bank, but this item contains an important conflict with the SBOK rule and should not be memorized without that qualification.

The SBOK change-management guidance states that requirements and Acceptance Criteria for User Stories completed in the current Sprint should not be altered retroactively. Specifically, the Scrum Master should prevent a completed User Story from being rejected merely because it fails newly changed requirements. Instead, the relevant Product Backlog Item should be revised to reflect the changed requirement and scheduled for a future Sprint.

Published versions of this legacy SMC practice item key C, which captures its intended notion that changed requirements belong in the Prioritized Product Backlog for later development. However, the phrase “deliverable is rejected on the basis of the changed requirements” is inconsistent with SBOK's explicit rule.

Therefore, for this historical exam item, C is the expected choice, but the technically correct SBOK principle is: evaluate current work against the original Acceptance Criteria and handle the changed requirement through a revised/new backlog item in a future Sprint.

Study Guide reference: Change - > Managing Changes During a Sprint; Acceptance Criteria Stability; Refine Prioritized Product Backlog.

========

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.

========

A Probability Impact Grid evaluates each identified risk according to two primary dimensions: its probability of occurrence and its potential impact on project objectives. SBOK explains that each dimension may be assigned a numerical or categorical rating and that probability and impact can then be combined to derive a risk-severity score.

That makes the technique particularly appropriate for the flood-and-landslide scenario. The team can estimate how likely these events are and assess the severity of their consequences for safety, cost, schedule, infrastructure, or environmental objectives. The resulting score helps determine prioritization and the urgency of mitigation.

Probability Trees model multiple possible outcomes as branches and calculate associated expected values. Pareto Analysis ranks identified risks by magnitude to focus attention on the most significant contributors. Expected Monetary Value converts uncertainty into a financial expectation by multiplying monetary impact by probability.

All four can support risk analysis, but the question specifically emphasizes evaluating probability and impact on project objectives, which directly matches the Probability Impact Grid.

Study Guide reference: Risk - > Risk Assessment - > Probability Impact Grid.

========

A deliverable that fails its User Story Acceptance Criteria is a Rejected Deliverable. It is not marked Done and normally returns to, or remains in, the Prioritized Product Backlog where it can be reprioritized and completed during a future Sprint. SCRUMstudy explicitly states that rejected User Stories are added back to the updated backlog for future Sprints.

Option A is therefore false because future correction is specifically permitted and expected when necessary. Option B incorrectly states that the Scrum Master defines Acceptance Criteria. They are primarily defined by the Product Owner based on customer requirements. Option D is incorrect because the objective is not to create increments that may satisfy Acceptance Criteria; completed deliverables should satisfy the applicable criteria before acceptance.

Carrying rejected work into a later Sprint is undesirable because the aim is to create potentially shippable, acceptable results during each Sprint, but Scrum provides a clear mechanism for managing such incomplete work.

Therefore, C accurately describes the handling of a rejected deliverable.

Study Guide reference: Review and Retrospect - > Demonstrate and Validate Sprint - > Accepted and Rejected Deliverables.

========

The intended exam answer is A — Better Team Coordination. In the legacy SBOK structure from which this question originates, Better Team Coordination is identified as a principal output of Convene Scrum of Scrums, not Demonstrate and Validate Sprint. That process focuses on coordination and integration among multiple Scrum Teams.

Demonstrate and Validate Sprint instead centers on showing completed Sprint work to the Product Owner, applying Acceptance Criteria, and obtaining acceptance or rejection. Legacy SBOK editions list Accepted Deliverables and Updated Dependencies among its outputs.

There is an important technical issue with this older question: the same legacy SBOK process tables also place Updated Impediment Log under Convene Scrum of Scrums rather than Demonstrate and Validate Sprint. Consequently, the question bank contains an overlapping distractor and is not perfectly constructed when checked literally against those process-output tables.

For exam-intent purposes, A is the expected response because Better Team Coordination is the distinctive mandatory output associated with Scrum of Scrums. Current SBOK editions have also revised process terminology and outputs, reinforcing the need to interpret this as a legacy SMC item.

Study Guide reference: Review and Retrospect - > Demonstrate and Validate Sprint; legacy Convene Scrum of Scrums outputs.

========

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.

========

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.

========

A Burndown Chart is the appropriate artifact for comparing work remaining over time with the expected or planned rate of completion. The chart normally plots remaining work against the Sprint timeline and therefore makes deviations from the planned trajectory visible.

If the actual remaining-work line stays above the planned line, the team may be progressing more slowly than expected. If it is below the planned trajectory, work is being completed faster than originally anticipated. The objective is not to measure individual performance but to provide transparent team-level information that supports inspection and adaptation.

A Scrumboard visualizes task status through workflow columns such as To Do, In Progress, and Done, but it does not inherently plot planned versus actual progress over time. A Cumulative Flow Diagram visualizes work distribution across workflow states and can reveal bottlenecks. A Kanban Board similarly focuses on workflow visualization.

The Burndown Chart therefore provides the clearest direct representation of planned versus actual remaining work, making C correct.

Study Guide reference: Implement/Plan and Estimate - > Sprint Burndown Chart; Transparency and Progress Tracking.

========

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.

========

Statements I and II correctly describe the purpose of Release Planning Sessions. SCRUMstudy states that Release Planning Sessions develop a plan defining when usable sets of functionality or products will be delivered. Their major objective is to give the Scrum Team an overview of releases and the delivery schedule so that development aligns with Product Owner and stakeholder expectations.

Statement III is inaccurate because the choice between continuous and phased deployment is described primarily as an organizational strategy, not simply something determined by stakeholder requirements. Organizations may release after specified functionality has been achieved or according to predefined release dates.

Statement IV is inconsistent with Scrum's adaptive approach. Release planning establishes a useful release roadmap or schedule but does not freeze a highly detailed plan for the entire project. Requirements, priorities, risks, and business conditions can evolve, and the release schedule can be updated accordingly.

Therefore, only statements I and II are correct.

Study Guide reference: Initiate - > Conduct Release Planning - > Release Planning Sessions and Release Planning Schedule.

========

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.

========

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.

Ownership of grooming—or in current terminology, refining—the Prioritized Product Backlog belongs primarily to the Product Owner, not the Scrum Master. SCRUMstudy explicitly states that the Product Owner leads backlog refinement, adds or revises User Stories, reprioritizes work, and ensures upcoming requirements are sufficiently refined.

The Scrum Master may facilitate Prioritized Product Backlog Review Meetings and help ensure that communication, estimation, and Scrum practices remain effective, but facilitation is not the same as owning or grooming the backlog.

The Scrum Master also coordinates creation of the Release Planning Schedule as part of Conduct Release Planning. SCRUMstudy's role mapping explicitly lists that responsibility.

Similarly, the Scrum Master can represent Scrum Core Team experience and lessons learned so that organizational knowledge and Scrum Guidance Body recommendations can improve.

The critical distinction is between facilitating backlog refinement and being accountable for the contents and prioritization of the backlog. The latter belongs to the Product Owner.

Therefore, A is the activity that is not a Scrum Master responsibility.

Study Guide reference: Organization - > Scrum Master Responsibilities; Implement - > Groom/Refine Prioritized Product Backlog.

========

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.

========

The Scrum Master should be selected based on characteristics such as problem-solving ability, availability, commitment, facilitation capability, and a supporting/servant leadership style. SCRUMstudy specifically identifies availability for meetings, skills for removing impediments, and commitment to maintaining a conducive work environment as relevant selection criteria.

Option D violates Scrum's principle of self-organization. The Scrum Master does not make technical implementation decisions on behalf of the Scrum Team. The Scrum Team has the authority and responsibility to determine how Prioritized Product Backlog Items are converted into finished deliverables. The Scrum Master's function is to facilitate, coach, protect the process, and remove obstacles—not to act as a technical project manager.

This distinction is fundamental. If the Scrum Master dictated technical decisions, responsibility would shift away from the self-organizing, cross-functional team and recreate a command-and-control structure inconsistent with Scrum.

Therefore, technical decision-making authority on behalf of the Scrum Team is not an appropriate Scrum Master selection criterion.

Study Guide reference: Organization - > Identify Scrum Master and Business Stakeholder(s) - > Selection Criteria; Scrum Team - > Self-organization and technical authority.

========