SMC Scrum Master Certified (SMC) Question and Answers

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

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

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

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

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

========

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

========

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.

========

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.

========

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.

========

Risk is explicitly one of the principal factors considered when constructing and prioritizing the Prioritized Product Backlog. SCRUMstudy identifies value, risk or uncertainty, and dependencies as three primary factors on which backlog prioritization is based.

Option A is therefore incorrect because dependencies may materially affect sequencing. One User Story may rely on functionality supplied by another, and such relationships must be considered during prioritization. SCRUMstudy also identifies splitting or combining stories as possible approaches for resolving dependencies.

Option B is too restrictive. Business value is important, but prioritization is not based only on subjective value. Risk, dependencies, business requirements, estimates, and other relevant considerations influence the ordering of work.

Option D is also incorrect because Scrum can use multiple prioritization techniques, including collaborative methods where appropriate. The framework does not establish a universal prohibition on voting.

Risk-aware prioritization allows high-risk or high-uncertainty work to be addressed early enough to expose problems and enable mitigation.

Study Guide reference: Business Justification - > Value-based Prioritization; Risk - > Risk-adjusted Prioritized Product Backlog.

========

Value-based Prioritization means that Scrum continually orders work so the most valuable requirements receive appropriate priority and business value can be delivered early and continuously, rather than being deferred until final project completion. SCRUMstudy describes this as a core Scrum principle focused on delivering maximum business value from early in the project and throughout its lifecycle.

Option A defines Time-boxing, where time functions as a limiting constraint. Option B defines Self-organization, which empowers the people performing the work. Option C defines Collaboration, specifically using the SBOK dimensions of awareness, articulation, and appropriation.

Value-based prioritization is implemented most visibly through the Prioritized Product Backlog. The Product Owner evaluates requirements by factors including value, risk/uncertainty, and dependencies and continually maintains the ordering as business conditions evolve.

The effect is that the Scrum Team works on high-value functionality without requiring the entire project's requirements to be delivered before stakeholders realize benefits.

Therefore, option D precisely states the SBOK definition.

Study Guide reference: Principles - > Value-based Prioritization; Business Justification - > Value-driven Delivery.

========

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.

========

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.

========

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.

========

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.

Statements II, III, and IV align with the Scrum Master's facilitative role. The Scrum Master ensures Scrum practices and processes are correctly followed, supports transparency and effective communication, facilitates Scrum meetings, and removes obstacles that interfere with successful delivery. SCRUMstudy describes the Scrum Master as the facilitator and supporting/servant leader who creates an environment conducive to team success.

Statement I is incorrect because strategic objectives and priorities are not defined by the Scrum Master. Strategic priorities are associated with Product Owner roles at the appropriate organizational level—for example, Program Product Owner or Portfolio Product Owner when Scrum is scaled. The Scrum Master supports execution of Scrum and removes impediments; the role does not own the business strategy.

Release Planning is also facilitated or coordinated by the Scrum Master while the Product Owner and Scrum Team participate in determining the release structure and Sprint length. Transparency is supported through visible artifacts, effective facilitation, and adherence to empirical process control.

Therefore, the valid combination is II, III, and IV.

Study Guide reference: Organization - > Scrum Master Responsibilities; Initiate - > Conduct Release Planning; Principles - > Empirical Process Control/Transparency.

========

Option C is false because User Story Acceptance Criteria are primarily defined by the Product Owner, based on the Product Owner's understanding of customer and business requirements. The Product Owner then communicates the User Stories and their criteria to the Scrum Team, and agreement and clarification are obtained. SCRUMstudy explicitly identifies Acceptance Criteria as objective conditions developed by the Product Owner.

The Scrum Master facilitates the process and ensures that agreed Acceptance Criteria are not inappropriately changed during an active Sprint, but the Scrum Master does not jointly own their definition with the Scrum Team.

Option D accurately reflects Scrum's iterative delivery approach: work is developed in short, time-boxed Sprints. Options A and B describe the more centralized quality and formal change-management characteristics typically associated with traditional project-management models in the SBOK comparison.

This distinction is important because Scrum incorporates quality continuously through Done Criteria, Acceptance Criteria, iterative development, inspection, adaptation, and frequent stakeholder feedback instead of treating quality primarily as a late project-control activity.

Study Guide reference: Quality - > Quality in Scrum versus Traditional Project Management; Acceptance Criteria; Product Owner Responsibilities.

========

Page

Scrum Master Certified (SMC®) — 100 Questions

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.

========

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.

========

The description corresponds to the Scrum Guidance Body (SGB). The SGB can provide organizational guidance, standards, regulations, recommended practices, templates, procedures, and lessons learned that Scrum Core Teams may use when appropriate.

In the backlog-refinement context, Scrum Guidance Body Recommendations can include guidance on how to understand and collate requirements, prioritize the backlog, document User Stories appropriately, and communicate changes to relevant participants.

Subject Matter Experts provide specialized knowledge based on particular technical or business domains, but the question specifically refers to documented organizational rules, development guidelines, standards, and best practices, which are characteristic of the Scrum Guidance Body.

Team Expertise refers to the collective capability of Scrum Team members to understand and execute Sprint work. Stakeholders contribute requirements, business needs, feedback, and priorities, but they are not the repository responsible for organizational Scrum standards.

The Scrum Guidance Body therefore provides consistency without converting Scrum into a centralized command-and-control methodology. Its recommendations support teams while still allowing appropriate tailoring.

Study Guide reference: Implement - > Groom/Refine Prioritized Product Backlog - > Scrum Guidance Body Recommendations.

========

SBOK establishes a specific exception to the general rule that Sprint scope remains unchanged once implementation begins. If the Scrum Team determines that it has significantly overestimated the effort required and consequently has genuine spare capacity, the team may ask the Product Owner which additional User Stories can be introduced into the current Sprint.

The Sprint Backlog and Sprint Burndown/Burnup information can make this situation visible by showing that work is being completed considerably faster than expected and that meaningful capacity remains.

Option A is insufficient because having highly skilled individuals does not itself authorize scope modification. Option B is also insufficient: one idle member does not necessarily mean the overall Scrum Team has enough capacity to complete another User Story. Option C concerns potential future Change Requests and provides no justification for disturbing the current Sprint.

The exception therefore applies when the team as a whole has overestimated effort and has spare capacity. Even then, the Scrum Team does not unilaterally select new work; it asks the Product Owner which additional prioritized User Story should be included.

Study Guide reference: Change - > Changes to a Sprint - > Exception for Overestimated Effort and Spare Capacity.

========

Page

Scrum Master Certified (SMC®) — 100 Questions

SCRUMstudy defines the Scrum Master primarily as a facilitator who ensures that the Scrum Team is provided with an environment conducive to successfully completing product development.

Options A and B describe Product Owner responsibilities. The Product Owner is responsible for maximizing business value, representing the Voice of the Customer, articulating customer requirements, and maintaining the business justification of the project. The Scrum Master supports these processes but does not own them.

Option C also improperly combines responsibilities. In larger Scrum initiatives, scaled roles such as Chief Scrum Master, Program Scrum Master, Chief Product Owner, or Program Product Owner may coordinate corresponding roles across teams or projects. A standard Scrum Master is not responsible for maintaining business justification across multiple Product Owners.

The Scrum Master's central duties instead include facilitating Scrum processes and meetings, coaching participants, removing impediments, protecting the team from disruptive interference, and maintaining a working environment in which a self-organizing team can succeed.

Therefore, D precisely reflects the SBOK definition.

Study Guide reference: Organization - > Core Roles - > Scrum Master; Product Owner; Supporting/Servant Leadership.

========

The intended process relationship is represented by option D. In the terminology used by this question set, Groom Prioritized Product Backlog continuously maintains and updates the backlog. A formal Prioritized Product Backlog Review Meeting is one of the principal mechanisms used to review requirements, obtain feedback, clarify User Stories, and incorporate appropriate changes. The resulting backlog is therefore updated and reprioritized.

Current SCRUMstudy materials use the term Refine Prioritized Product Backlog rather than “Groom,” but the underlying concept remains essentially the same: the Product Owner leads backlog maintenance with input from the Scrum Master, Scrum Team, and relevant business stakeholders.

Accepted Deliverables belong to Demonstrate and Validate Sprint, while the Sprint Backlog is created in planning rather than as the output of backlog refinement. Likewise, a Retrospect Sprint Meeting focuses on lessons learned and actionable improvements.

Thus, the valid Input/Tool/Output combination among the choices is D.

Study Guide reference: Implement - > Groom/Refine Prioritized Product Backlog - > Prioritized Product Backlog Review Meeting - > Updated Prioritized Product Backlog.

========

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.

========

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.

========

The incorrect statement targeted by this question is statement II. A Scrumboard is fundamentally a Scrum Team information radiator used to visualize and track Sprint work. SCRUMstudy explains that the team uses the Scrumboard to plan and track progress and that it can be maintained manually on paper or a whiteboard, or electronically.

Stakeholders may be able to observe the board because Scrum promotes transparency, but the board is not described as a stakeholder-owned planning and progress-control mechanism. Sprint execution remains with the self-organizing Scrum Team.

The exact number of columns has varied across SBOK editions and examples. Typical layouts include To Do, In Progress, Testing, and Done; other representations may include an additional Stories column. Therefore, the essential exam concept is not a rigid visual format but the board's role in transparently showing Sprint task status. During implementation it is continually updated as work progresses, and a fresh board is used for the subsequent Sprint.

Thus statement II incorrectly assigns ownership/use to stakeholders rather than the Scrum Team.

Study Guide reference: Implement - > Create Deliverables - > Scrumboard; Empirical Process Control - > Transparency.

========

This scenario describes Refactoring. SBOK defines refactoring as improving the internal design or structure of existing software while preserving its externally observable functionality. The objective is to make code more concise, maintainable, flexible, and understandable without changing what the software does.

The scenario specifically states that the existing implementation is complex, redundant, and time-consuming to maintain, while functionality must remain intact. Those are classic refactoring conditions. Typical refactoring work can include eliminating duplicated code, simplifying overly complicated logic, separating responsibilities, improving naming and structure, and reducing unnecessary coupling.

Design Patterns differ because they provide reusable documented solutions to recurring design problems. A team might employ a design pattern while refactoring, but “Design Patterns” does not describe the overall activity of restructuring existing code without changing behavior.

Mitigated Risks and Updated Dependencies are project-management outputs rather than software-engineering techniques for internal code improvement.

Therefore, the defining combination—redesign internal code, remove redundancy, improve maintainability, preserve functionality—identifies refactoring unambiguously.

Study Guide reference: Quality/Implement - > Create Deliverables - > Refactoring; technical practices for maintaining product quality.

========

Option C incorrectly describes the Probability Impact Grid. In SBOK, the Probability Impact Grid evaluates each individual risk by assigning values to both probability and impact. Those ratings are then combined—commonly by multiplication—to derive a risk-severity or PI score for prioritization.

The wording in C—calculating an overall impact from the values of multiple possible events or outcomes—is more closely associated with Probability Trees, where potential outcomes are represented by separate branches with associated probabilities and impacts.

Option A is correct. Expected Monetary Value equals the monetary impact of a risk multiplied by its probability of occurrence. Option B is correct because Pareto Analysis ranks risks according to magnitude, enabling attention to be focused on the most consequential risks. Option D also correctly describes Probability Trees, where each potential outcome is represented graphically through branching alternatives.

Thus the mismatched technique-description pairing is C.

Study Guide reference: Risk - > Risk Assessment Techniques - > Probability Trees, Pareto Analysis, Probability Impact Grid, Expected Monetary Value.

========

The Scrum Master facilitates planning rather than performing the team's estimates. Consequently, acting as the moderator and impediment remover is the correct responsibility.

During task estimation, the Scrum Team determines the effort necessary to accomplish tasks associated with committed User Stories. The resulting Effort Estimated Task List provides the estimated work associated with Sprint tasks and supports creation or updating of the Sprint Backlog. SCRUMstudy confirms that task estimation is performed by the Scrum Team and that the Scrum Master supports and facilitates the relevant meetings rather than imposing estimates.

Option B is not the objective of Scrum Master facilitation; diverse perspectives can naturally emerge, but they are not something the Scrum Master artificially ensures. Option C incorrectly suggests that the Scrum Master determines how tasks should be decomposed or estimated. That authority rests with the self-organizing Scrum Team. Option D is logically defective and reflects an obvious wording problem in the supplied question.

The Scrum Master therefore enables effective planning by maintaining the process, facilitating discussion, removing obstacles, and ensuring that the team—not the facilitator—owns the estimates.

Study Guide reference: Plan and Estimate - > Estimate Tasks - > Effort Estimated Task List; Sprint Planning Meeting; Scrum Master facilitation.

========