Pass the Scrum Master Certified SMC Questions and answers with Dumpstech

Among the options given, the Retrospect Project Meeting is the correct answer. SBOK describes this meeting as being conducted after the project to determine ways in which team collaboration and effectiveness can be improved in future projects. Participants examine successes, failures, inefficiencies, and potential improvement opportunities and document lessons learned.

At Sprint level, the equivalent continuous-improvement event is the Retrospect Sprint Meeting, where the team determines what to continue, start, or stop doing in future Sprints. However, that choice is not present in this question.

Sprint Planning is concerned with selecting and planning upcoming Sprint work. Sprint Review/Demonstrate and Validate Sprint focuses on inspecting deliverables and obtaining Product Owner/stakeholder feedback. “Review Project Meeting” is not the defined SBOK retrospective event represented here.

Because this question asks specifically about improving collaboration and effectiveness in the future, and because Retrospect Sprint is absent from the options, Retrospect Project is the correct meeting.

Study Guide reference: Release - > Retrospect Project - > Lessons Learned and Future Improvement.

========

Statement C is false because risks differ substantially in both probability and impact. Risk assessment exists precisely to distinguish more significant risks from less significant ones.

SCRUMstudy defines risk as an uncertain event or set of events capable of affecting project objectives positively or negatively. Positive risks are called opportunities, while negative risks are threats.

Risk management is iterative and begins during project initiation, continuing throughout the project lifecycle. Risks are assessed primarily on their probability of occurrence and potential impact. Risks with high probability and high impact should generally receive greater attention than low-probability, low-impact risks.

This prioritization enables limited resources to be allocated rationally. Techniques such as Probability Impact Grids, Probability Trees, Expected Monetary Value, and Pareto Analysis help teams assess and compare exposures.

Therefore, the claim that all risks possess equal probability and impact directly contradicts the central mechanism of SBOK risk assessment and prioritization.

Study Guide reference: Risk - > Definition of Risk; Risk Assessment and Risk Prioritization.

========

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.

========

All four questions are explicitly associated with the Scrum of Scrums (SoS) Meeting. The purpose of the meeting is to coordinate multiple Scrum Teams working on the same large project or on strongly interdependent work.

SCRUMstudy lists all four questions: what the team has worked on since the previous meeting; what it will work on before the next meeting; what other teams expected it to finish that remains incomplete; and what upcoming activities might affect other teams.

The first two provide cross-team visibility into progress and upcoming activity. The third exposes delayed inter-team dependencies. The fourth identifies potential future conflicts, shared-resource issues, interface changes, or other work that can affect neighboring teams.

These questions make SoS more than a status meeting. They support dependency management, early risk identification, integration, transparency, and coordination across team boundaries. The Chief Scrum Master, or another facilitating Scrum Master, normally facilitates the meeting.

Since I, II, III, and IV are all standard SoS questions, D is correct.

Study Guide reference: Organization - > Scaling Scrum - > Scrum of Scrums Meeting.

========

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.

========

The Scrum Master is fundamentally a facilitator and supporting/servant leader rather than a traditional command-and-control project manager. Within the quality aspect, the Scrum Master's responsibilities include eliminating environmental obstructions that can negatively affect either the quality of deliverables or the effectiveness of Scrum processes.

Environmental obstructions may include organizational interference, inadequate tools, coordination problems, communication barriers, disruptive working conditions, or dependencies that prevent the Scrum Team from working effectively. The Scrum Master facilitates their removal so the self-organizing Scrum Team can concentrate on producing high-quality deliverables.

“Leader” is too broad for the specific role described in this question. Although servant leadership is a characteristic of a Scrum Master, the operational action of clearing impediments and creating a conducive environment is fundamentally facilitative. “Pacifier” and “Escalator” are not formal Scrum roles.

The distinction matters because the Scrum Master does not solve the technical work for the team or direct members on how to build deliverables. Instead, the role improves the environment and process in which the team operates.

Study Guide reference: Quality - > Summary of Responsibilities Relevant to Quality; Organization - > Scrum Master as Facilitator/Supporting Leader.

========

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.

========

Statements II and IV are correct.

SBOK describes the Retrospect Project Meeting as a forum where the project participants examine positives, negatives, and potential opportunities for improvement. The meeting also explicitly captures and documents lessons learned so that they can be internalized and applied to future projects.

Statement III is false because the Retrospect Project Meeting is not Time-boxed, although it may indeed be conducted physically or virtually. Because the statement combines one false and one true condition, the complete statement is false.

Statement I is not an accurate description of the principal meeting objective. Scrum Guidance Body recommendations may address mechanisms for maintaining organizational knowledge, but the Retrospect Project Meeting itself primarily examines overall project experience, team effectiveness, collaboration, lessons, and improvement opportunities.

This meeting differs from Retrospect Sprint in scope. Retrospect Sprint seeks improvements for subsequent Sprints within an ongoing project, whereas Retrospect Project captures broader learning after completion.

Therefore, statements II and IV are the supported pair.

Study Guide reference: Release - > Retrospect Project - > Retrospect Project Meeting and Lessons Learned.

========

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.

========

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.

========