SMC Exam Dumps - Scrum Master Certified Questions and Answers

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.

========

Statement B is inaccurate because SBOK risk management operates across project, program, and portfolio levels. A risk may originate at the program or portfolio level yet affect one or more projects. In such circumstances, information about that risk must be communicated to the affected Product Owner and Scrum Team, while the risk can continue to be managed at the level where it originated. Serious portfolio/program risks can even cause a project team to reconsider or re-plan Sprint work.

Scrum's iterative structure also reduces exposure by creating short feedback cycles. Problems become visible sooner than in long sequential delivery models, allowing corrective action before excessive investment accumulates. Risk information can be communicated through artifacts such as Risk Burndown Charts.

Scrum's flexibility further assists risk management because approved changes can be incorporated into the Prioritized Product Backlog and prioritized for subsequent Sprints. This does not mean uncontrolled scope changes are introduced into an active Sprint; Sprint stability remains protected.

Therefore, the assertion that risks can only be managed at project level directly contradicts SBOK's treatment of program- and portfolio-level risk.

Study Guide reference: Risk - > Risks in Portfolios and Programs; Risk Identification, Assessment, Prioritization, and Communication.

========

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

========

Velocity measures the amount of estimated work successfully completed by a Scrum Team during a Sprint. Where User Stories are estimated in story points, Sprint velocity is normally calculated by totaling the story-point values of the User Stories completed during that Sprint. SCRUMstudy explicitly describes velocity in these terms.

Velocity is particularly useful because historical values can support future Sprint planning and release forecasting. After several Sprints, a reasonably stable team can use its observed velocity to estimate how much work it is realistically capable of completing in a similar Sprint.

Business Value Delivered measures value rather than effort points. Number of Stories counts items without considering their relative size—a Sprint containing five small stories is not necessarily equivalent to one containing five large stories. A Sprint Burndown Chart shows remaining work over time during the Sprint rather than defining the quantity of story points successfully delivered.

Therefore, the metric that directly captures the number of completed story points per Sprint is Velocity.

Study Guide reference: Plan and Estimate - > Estimation; Implement - > Sprint Metrics; Velocity and Story Points.

========

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.

========

SBOK defines risk as an uncertain event or set of events that can affect project objectives. Importantly, risk is not necessarily negative. Risks with potentially favorable consequences are classified as opportunities, whereas risks capable of producing adverse outcomes are called threats. SCRUMstudy explicitly distinguishes these two categories.

In this scenario, additional orders have not yet materialized, so they remain uncertain. However, if they occur, they would generate a positive business consequence attributable to successful project performance. That makes the event a positive risk—an opportunity.

An issue differs from a risk because an issue has already occurred and therefore is no longer uncertain. “Weakness” may be used in analytical techniques such as SWOT Analysis but is not the correct risk classification in this scenario. A threat would apply if the uncertain event could negatively affect objectives.

Because future orders represent uncertainty with a beneficial potential impact, the correct classification is Opportunity.

Study Guide reference: Risk - > Definition of Risk - > Opportunities and Threats; Risk Identification and Assessment.

========

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

========

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.

========