Pass the Scrum Master Certified SMC Questions and answers with Dumpstech

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.

========

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.

========

The standard SBOK User Story format is:

As a < role/persona > , I should be able to < requirement > so that < benefit > .

A User Story therefore expresses three essential dimensions: Who, What, and Why. The “Why” component identifies the benefit or value expected from satisfying the requirement.

Option D directly corresponds to that third component: What benefit is expected from the requirement? This helps ensure that functionality is connected to user or business value rather than being treated simply as an isolated technical request.

Cost of development is addressed through estimation and business-justification activities rather than the core User Story template. The specific individual responsible for performing the work is not embedded in a User Story because Scrum Teams are self-organizing and determine task ownership during planning and execution. Testing techniques may influence tasks or Acceptance Criteria but are not one of the three core User Story template elements.

Therefore, the expected benefit is the relevant question.

Study Guide reference: Plan and Estimate - > Create User Stories - > User Story Template: Role/Persona, Requirement, Benefit.

========

This scenario represents Risk Mitigation because concrete responses are being developed to reduce or manage the consequences of identified risks.

SBOK defines risk mitigation as developing an appropriate strategy to deal with risk. Mitigation can include proactive responses designed to reduce probability or impact and reactive contingency actions to be implemented if the event occurs.

Strengthening or safeguarding the infrastructure is a proactive mitigation measure because it reduces the potential physical impact of earthquakes or tsunamis. Establishing a contingency reserve provides resources that can be used reactively if the disaster actually occurs.

Risk Assessment would involve evaluating probability and potential impact but would not itself implement safeguards. Risk Prioritization would determine which identified risks require the greatest attention. Risk Avoidance would involve eliminating the underlying exposure entirely—for example, redesigning the project so that the threatened infrastructure was no longer exposed to the disaster risk.

Because the proposed actions reduce impact and prepare contingency capability rather than eliminating the risk altogether, Risk Mitigation is correct.

Study Guide reference: Risk - > Risk Management - > Risk Mitigation; Proactive and Reactive Risk Responses.

========

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

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

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

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

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

========

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 SBOK framework identifies six Scrum principles: Empirical Process Control, Self-organization, Collaboration, Value-based Prioritization, Time-boxing, and Iterative Development. These principles are fundamental and apply across Scrum projects regardless of industry or product type.

Self-organization allows team members to determine how best to accomplish their work rather than relying on command-and-control assignment. Collaboration supports shared value creation and effective interaction among the Scrum Core Team and stakeholders. Value-based Prioritization ensures that higher-value requirements receive appropriate priority so that business value can begin to be delivered early.

Linear product delivery, however, is inconsistent with Scrum. Linear or sequential delivery is characteristic of approaches in which major project phases occur predominantly one after another. Scrum instead relies on short, repeated iterations in which work is planned, developed, reviewed, and adapted continuously.

Therefore, linear product delivery is not one of the Scrum principles.

Study Guide reference: Principles - > Six Scrum Principles - > Self-organization, Collaboration, Value-based Prioritization, Iterative Development.

========

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.

========