Practice Free SMC Scrum Master Certified (SMC) Exam Questions Answers With Explanation

The Chief Scrum Master is the designated role responsible for coordinating multiple Scrum Masters and facilitating cross-team integration in a large Scrum project. The Scrum of Scrums Meeting is one of the principal mechanisms used for this purpose.

Each Scrum Team normally sends a representative—often its Scrum Master—who communicates team progress, upcoming activities, dependencies, impediments, and work that could affect other teams. The meeting allows problems spanning several teams to be identified and coordinated at an appropriate level.

A Product Owner manages business value and requirements for a product or project scope. A Portfolio Product Owner operates at the broader portfolio level and is concerned with strategic prioritization and portfolio value. A Sponsor provides business support and funding. None of these roles normally facilitates the Scrum of Scrums.

SCRUMstudy's scaling guidance describes synchronization across multiple teams as essential to large-project Scrum and assigns this coordination responsibility to scaled Scrum leadership structures.

Therefore, Chief Scrum Master is correct.

Study Guide reference: Organization - > Scrum for Large Projects - > Chief Scrum Master and Scrum of Scrums.

========

The Skills Requirement Matrix, also described as a competency framework, is specifically intended to map the competencies available within a team and identify development needs. SCRUMstudy's SBOK glossary states that this matrix is used to assess skill gaps and training requirements while mapping team members' skills, capabilities, and interest in applying those capabilities to the project.

This makes option A an exact match to the scenario.

An Organizational Deployment Method concerns how a release or organizational change may be introduced and does not map individual competencies. A Daily Standup enables coordination, status synchronization, and identification of impediments, but it is not a formal competency-assessment tool. “Organizational Resource Matrix” is not the SBOK tool defined for the detailed skills analysis described.

A Skills Requirement Matrix can therefore help identify whether sufficient expertise exists to satisfy project needs, where cross-training may be appropriate, and which team members require additional training. It also assists during team formation and capability planning.

Study Guide reference: Organization - > Form Scrum Team - > Skills Requirement Matrix/Competency Framework; Team capability and training requirements.

========

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.

========

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 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.

========

Earned Value Analysis (EVA) does not primarily increase awareness of the components, activities, and development sequence of a product. EVA is fundamentally a performance-measurement technique that compares planned value, earned value, and actual cost to assess cost and schedule performance.

By contrast, a Product Breakdown Structure decomposes the product into constituent components, increasing understanding of what must be created. A Work Breakdown Structure organizes the work required to create project outputs, improving awareness of activities and relationships. A Product Flow Diagram illustrates the sequence in which product components are created or integrated.

These techniques support the awareness dimension of collaboration because team members can understand what work exists, how components relate, and how activities interact. SBOK defines collaboration in terms of awareness, articulation, and appropriation, with awareness involving knowledge of one another's work and the overall project environment.

Earned Value Analysis instead measures performance against a baseline and therefore does not directly perform the structural or workflow-visualization function described in the question.

Study Guide reference: Principles - > Collaboration - > Awareness; project/product visualization techniques.

========

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.

========

Successful release depends fundamentally on the Scrum Team creating the agreed deliverables so that completed and accepted work can eventually be transitioned to the customer or other relevant business stakeholders. The Release phase's Ship Deliverables process handles accepted deliverables, while the Product Owner coordinates deployment with the customer.

Option B describes activities associated with the Product Owner following validation and backlog/release-plan management rather than the specific condition the Scrum Master must ensure for successful creation of releasable work.

Option C is incorrect because the Release Planning Schedule is developed during Conduct Release Planning, involving the Product Owner and Scrum Core Team; it is not simply created by the Scrum Team during Ship Deliverables.

Option D incorrectly assigns acceptance authority. During Demonstrate and Validate Sprint, the Product Owner, not the Scrum Team, accepts or rejects completed User Stories against their Acceptance Criteria.

Therefore, ensuring that the Scrum Team creates the committed deliverables as agreed provides the necessary basis for later acceptance and release.

Study Guide reference: Release - > Ship Deliverables; Implement - > Create Deliverables; Review and Retrospect - > Demonstrate and Validate Sprint.

========

Option C reverses the actual Scrum-versus-traditional distinction. In Scrum, Return on Investment and business value can begin early and continue throughout the project lifecycle because potentially valuable increments are produced iteratively. Traditional sequential projects frequently defer realization of substantial value until the completed product is delivered. SCRUMstudy's comparison explicitly lists Scrum ROI as “early/throughout project life” and traditional ROI as occurring at the end of project life.

The other statements correctly reflect SBOK's comparison. Scrum organizations are self-organized rather than centrally managed. Scrum places greater emphasis on people and collaborative responsibility, whereas traditional management generally emphasizes formally defined processes. Scrum's quality philosophy is customer-centric and centered on delivering working outcomes that satisfy customer requirements and Acceptance Criteria, whereas traditional approaches are described as more process-centric.

Therefore, C is not merely a subtle difference—it states the ROI relationship in exactly the opposite direction.

Study Guide reference: Introduction to Scrum/Business Justification - > Scrum versus Traditional Project Management; Value-driven Delivery.

========

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.

========

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.

========

Statements I, III, and IV are correct. Dependencies represent relationships among User Stories or tasks that constrain or influence the sequence in which work should be performed. SBOK classifies dependencies in several ways, including mandatory versus discretionary and internal versus external. Mandatory dependencies are inherent in the nature of the work; discretionary dependencies are introduced by choice, convention, preference, or workflow design.

Dependencies also highlight interaction between tasks and help determine the most logical execution sequence. Documenting them is especially important where multiple Scrum Teams, technical components, specialists, or external suppliers are involved.

Statement II is false. Dependencies are explicitly one of the three major factors considered when prioritizing the Prioritized Product Backlog, alongside value and risk/uncertainty. The Product Owner must account for implementation dependencies when determining ordering.

Where appropriate, dependencies among User Stories can also be reduced or resolved by splitting overly large stories or restructuring/combining related requirements.

Thus I, III, and IV accurately describe dependency management, making option B correct.

Study Guide reference: Plan and Estimate - > Identify Tasks - > Dependencies; Value-based Prioritization - > Dependencies.

========

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.

========

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 technically relevant principle is that business justification must be reassessed whenever major issues or risks threaten viability, making D the intended answer. SBOK states that business justification is initially assessed before project initiation and continuously verified throughout the lifecycle. Verification occurs at predefined intervals or milestones and also whenever significant issues or risks arise that could undermine the rationale for continuing the investment.

Option C overstates “continuous” by interpreting it as literal day-to-day formal review. Continuous Value Justification means that viability remains subject to ongoing validation; it does not require a complete business-case reassessment every working day. Option A is too late because justification must be maintained while investment decisions can still be changed. Option B imposes an every-Sprint portfolio review requirement that SBOK does not establish universally.

The question's repeated use of “portfolio business justification” is imperfectly aligned with the opening reference to a Product Owner. Strictly, project-level business justification is owned primarily by the Product Owner, while portfolio-level justification belongs to the Portfolio Product Owner. Nevertheless, the substantive business-justification trigger described in D is correct.

Study Guide reference: Business Justification - > Continuous Value Justification; Project Viability; Major Issues and Risks.

========

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 Product Owner defines the User Story Acceptance Criteria based on understanding of customer and business requirements, but once a User Story has been committed to an active Sprint, the Scrum Master is responsible for protecting the team from inappropriate mid-Sprint alteration of those criteria.

SCRUMstudy explicitly assigns the Scrum Master responsibility for ensuring that Acceptance Criteria are not changed by the Product Owner in the middle of the Sprint.

This preserves Sprint stability and prevents completed or partially completed work from being judged retrospectively against requirements that did not exist when the team made its commitment. New or changed requirements are normally reflected in the Prioritized Product Backlog and considered for a subsequent Sprint.

The Sponsor, customers, and users may supply feedback and business requirements, but they do not control the active Sprint's Acceptance Criteria. The Product Owner owns the criteria but is precisely the role whose mid-Sprint changes must be controlled.

Therefore, the Scrum Master ensures that the agreed Acceptance Criteria remain stable for the committed Sprint.

Study Guide reference: Quality - > User Story Acceptance Criteria; Change - > Maintaining Sprint Stability; Scrum Master responsibilities.

========

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.

========

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 Risk Breakdown Structure (RBS) is specifically designed to organize identified risks into logical categories based on common characteristics or sources. SCRUMstudy describes an RBS as a technique in which risks are grouped according to categories or commonalities—for example, financial, technical, operational, safety, regulatory, or external risks. This hierarchical categorization makes a potentially large collection of risks easier to analyze and manage.

The other options serve different purposes. A Risk Checklist helps ensure that commonly encountered risks are not overlooked. A Risk Prompt List stimulates thinking about possible risk sources. Brainstorming generates potential risks through collaborative discussion among knowledgeable participants. None of those techniques is primarily intended to categorize and structure already identified risks according to similarities.

The wording “categorize and organize” is therefore decisive. Once risks have been identified, an RBS provides a structured view that facilitates further assessment, ownership, prioritization, and response planning.

Consequently, Risk Breakdown Structure is the appropriate technique.

Study Guide reference: Risk - > Risk Identification - > Risk Breakdown Structure; Risk Checklists; Risk Prompt Lists; Brainstorming.

========

The Initiate phase establishes the foundation of the Scrum project. SCRUMstudy identifies its processes as Create Project Vision, Identify Scrum Master and Business Stakeholder(s), Form Scrum Team, Develop Epic(s), Create Prioritized Product Backlog, and Conduct Release Planning. Therefore, identifying the Scrum Master and relevant stakeholders is explicitly an Initiate-phase activity.

The remaining options belong to later phases. Estimating and committing User Stories form part of Plan and Estimate, where requirements selected from the Prioritized Product Backlog are analyzed, estimated, and committed for upcoming Sprint work. Conduct Daily Standup belongs to Implement, because it occurs while the Scrum Team is executing Sprint work and synchronizing daily activities.

This phase separation is important in SMC questions. Initiate establishes the vision, roles, high-level requirements, prioritized backlog, and initial release structure. Plan and Estimate converts prioritized requirements into executable Sprint-level work. Implement concerns actual creation of deliverables and daily coordination.

Accordingly, Identify Scrum Master and Stakeholder(s) is the only option that is explicitly part of the Initiate phase.

Study Guide reference: Initiate - > Identify Scrum Master and Business Stakeholder(s); Plan and Estimate - > Estimate/Commit User Stories; Implement - > Conduct Daily Standup.

========

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.

========

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.

========

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