SMC Questions and Answers

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.

========

SBOK defines six non-negotiable Scrum principles:

1. Empirical Process Control

2. Self-organization

3. Collaboration

4. Value-based Prioritization

5. Time-boxing

6. Iterative Development

Collaboration is therefore a Scrum principle and focuses on awareness, articulation, appropriation, and shared value creation. Value-based Prioritization ensures that the project continuously focuses on work producing the greatest business value. Iterative Development allows teams to repeatedly build, inspect, obtain feedback, and adapt to changing requirements.

Manage by Stages is not an SBOK Scrum principle. It is terminology associated particularly with PRINCE2's project-management principles, where a project is planned, monitored, and controlled stage by stage.

Although Scrum does divide work into Sprints, this should not be confused with the “Manage by Stages” principle. Scrum Sprints are iterative, adaptive development cycles rather than traditional management stages.

Therefore, C is not one of SBOK's six Scrum principles.

Study Guide reference: Principles - > Six Scrum Principles.

========

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.

========

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 Project Vision Statement establishes the project's overall direction and communicates the fundamental business objective that the project is intended to achieve. During Create Project Vision, the Project Business Case is reviewed and the Project Vision Statement is produced to provide inspiration and focus for the entire project.

SCRUMstudy further emphasizes that a good project vision focuses on the business need or problem, rather than prematurely prescribing the detailed solution. It should not be so specific that adaptation becomes difficult as assumptions and requirements evolve.

Specific requirements are subsequently developed through Epics, User Stories, and the Prioritized Product Backlog. Project status is communicated through Scrum artifacts and meetings, while daily progress is tracked through mechanisms such as Daily Standups, Scrumboards, and Sprint Burndown Charts.

Consequently, the Project Vision is neither a detailed requirements specification nor a daily control document. Its primary function is to define the high-level objective and desired direction of the project.

Study Guide reference: Initiate - > Create Project Vision - > Project Business Case and Project Vision Statement.

========

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.

========

Option C contains the intended SBOK responsibility mapping. The Sponsor provides resources and financial support for the project. The Scrum Guidance Body (SGB) establishes organizational guidance, including recommendations concerning business justification techniques and other Scrum practices. The Scrum Master facilitates creation of project deliverables and helps manage risks, changes, and impediments through Scrum processes.

Customers and users constitute important business stakeholders whose requirements and expected value feed the Prioritized Product Backlog. In the formal core-role model, the Product Owner consolidates, articulates, and prioritizes those requirements as the Voice of the Customer; therefore, statement b should be understood in this question's stakeholder-input context rather than as transferring Product Owner accountability to customers. SCRUMstudy identifies the Product Owner as the role responsible for representing stakeholder interests and maintaining prioritized requirements.

The other mappings incorrectly assign funding, guidance, or facilitation responsibilities.

Thus the intended mapping is Sponsor - > c; SGB - > d; Customers/Users - > b; Scrum Master - > a.

Study Guide reference: Business Justification - > Responsibilities of Scrum Roles; Organization - > Sponsor, Business Stakeholders, Scrum Guidance Body, Scrum Master.

========

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 Product Owner has primary accountability for project-level business justification, including ensuring value delivery and maintaining the project's business rationale. The Scrum Master's role is facilitative: helping ensure that desired outcomes are understood, coordinating with the Product Owner and Scrum Team, and supporting Continuous Value Justification throughout execution.

SBOK's responsibility model assigns the Product Owner responsibility for value delivery and maintenance of project business justification, while the Scrum Master supports continuous justification and ensures that the project's desired outcomes are communicated and understood by the Scrum Team.

Therefore, A is incorrect because creation and confirmation of project business justification belong principally to the Product Owner. B likewise represents Product Owner accountability. D is also primarily assigned to the Product Owner, who is responsible for maximizing and ensuring project value.

Option C best represents the Scrum Master's supporting role. Through Sprint execution, risk/change facilitation, communication, and coordination with the Product Owner, the Scrum Master helps verify that continued investment remains aligned with the expected business outcomes.

Study Guide reference: Business Justification - > Summary of Responsibilities; Continuous Value Justification; Product Owner and Scrum Master roles.

========

Page

Scrum Master Certified (SMC®) — 100 Questions

A Burndown Chart is the appropriate artifact for comparing work remaining over time with the expected or planned rate of completion. The chart normally plots remaining work against the Sprint timeline and therefore makes deviations from the planned trajectory visible.

If the actual remaining-work line stays above the planned line, the team may be progressing more slowly than expected. If it is below the planned trajectory, work is being completed faster than originally anticipated. The objective is not to measure individual performance but to provide transparent team-level information that supports inspection and adaptation.

A Scrumboard visualizes task status through workflow columns such as To Do, In Progress, and Done, but it does not inherently plot planned versus actual progress over time. A Cumulative Flow Diagram visualizes work distribution across workflow states and can reveal bottlenecks. A Kanban Board similarly focuses on workflow visualization.

The Burndown Chart therefore provides the clearest direct representation of planned versus actual remaining work, making C correct.

Study Guide reference: Implement/Plan and Estimate - > Sprint Burndown Chart; Transparency and Progress Tracking.

========

The technique described is Planning Poker. In Planning Poker, Scrum Team members receive decks containing numerical values, commonly based on a modified Fibonacci sequence. After discussing a User Story or task, every estimator independently selects a card representing the relative effort, size, or complexity of that item. The cards are then revealed, and differences in estimates trigger further discussion until sufficient consensus is achieved.

Fist of Five uses fingers rather than numbered card decks and is useful for estimation or rapid consensus-building. Wideband Delphi involves repeated independent estimates and discussion but does not inherently require Planning Poker cards. Affinity Estimation instead groups or orders items by relative size.

Planning Poker combines individual judgment with collaborative discussion. Simultaneous revelation also reduces anchoring because one participant's estimate cannot influence everyone else's initial estimate before they have committed to a value.

The explicit reference to a deck of numbered cards and each member selecting a card corresponding to an estimate makes Planning Poker unambiguous.

Study Guide reference: Plan and Estimate - > Estimate User Stories/Estimate Tasks - > Planning Poker; Relative Estimation.

========

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.

========

A Program Scrum Master extends the facilitative Scrum Master role from an individual project to the program level. SCRUMstudy describes the Program Scrum Master as responsible for guiding, facilitating, and teaching Scrum practices to those involved in the program; helping remove program-level impediments; supporting individual project Scrum Masters; and ensuring that Scrum processes are followed effectively.

Option B is associated more closely with the Program Product Owner, who establishes strategic objectives and priorities for the program and ensures alignment of component projects with program outcomes.

Option A improperly assigns ownership of business justification and viability creation to the Program Scrum Master. Business justification is primarily a Product Owner/business responsibility, although the Scrum Master may facilitate relevant processes.

Option D is inconsistent with Scrum because the Program Scrum Master does not directly control project teams. Scrum Masters facilitate self-organizing teams rather than exercising command authority over them.

Thus the correct responsibility is facilitating and teaching Scrum practices throughout the program.

Study Guide reference: Organization - > Scrum in Programs and Portfolios - > Program Scrum Master responsibilities; Supporting Leadership.

========

The Retrospect Project Meeting is the meeting described in the relevant SBOK edition as not Time-boxed and capable of being conducted either in person or virtually. Its objective is broader than a Sprint-level retrospective: participants evaluate the overall project, document lessons learned, discuss positive and negative experiences, and identify opportunities to improve future projects.

SCRUMstudy specifically describes this meeting as not being Time-boxed and notes that it may take place physically or in a virtual format.

The other choices are Time-boxed Scrum events. The Daily Standup has a strict short duration. Sprint Planning is Time-boxed according to Sprint length, and Sprint Review/Demonstrate and Validate Sprint is also conducted within a defined time-box.

The rationale is that Retrospect Project occurs after the broader project lifecycle and may involve examining substantial lessons, organizational practices, knowledge transfer, transition matters, and stakeholder feedback. It therefore does not carry the same fixed execution-cycle constraint as recurring Sprint events.

Accordingly, the correct answer is B.

Study Guide reference: Review and Retrospect/Release - > Retrospect Project Meeting; Lessons Learned; Continuous Improvement.

========

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.

========

Within the SBOK framework reflected by this SMC question set, the recommended Scrum Team size is six to ten members. This range is intended to provide enough cross-functional capability to create the Sprint deliverables while keeping coordination and communication manageable.

If a team becomes too large, communication channels increase rapidly, meetings become more difficult to manage, self-organization becomes less efficient, and individual accountability can become diluted. Large projects are therefore normally handled through multiple Scrum Teams coordinated using mechanisms such as Scrum of Scrums rather than by constructing a single excessively large team.

Conversely, a very small team may not contain sufficient breadth of skills to function cross-functionally or may become vulnerable when one person is unavailable.

Therefore, among the choices presented, six to ten is the intended SBOK answer.

Study Guide reference: Organization - > Scrum Team - > Team Size and Personnel Selection; Scaling Scrum - > formation of multiple Scrum Teams for larger projects.

========

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.

========

Takeuchi and Nonaka's work is historically important because it explicitly contrasted the new product-development model with the traditional sequential relay-race approach. They did not recommend sequential development. Instead, they described a holistic or rugby-style model in which a multidisciplinary team progresses together toward a common objective.

The rugby metaphor emphasized overlapping activities, collaboration, adaptability, and shared responsibility rather than handing work sequentially from one specialist group to another. Their observations were derived from case studies involving organizations across several manufacturing industries. This conceptual foundation later contributed to what became known as Scrum.

Therefore, option B reverses the historical argument. The sequential relay-race model was the approach Takeuchi and Nonaka were challenging, whereas the rugby model represented the flexible, integrated alternative they advocated.

Options A, C, and D accurately describe the historical background presented by SCRUMstudy: the rugby analogy, team-based development toward a shared objective, and the use of cross-industry manufacturing case studies.

Study Guide reference: Introduction to Scrum - > History of Scrum; traditional sequential product development versus the holistic/rugby approach.

========

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.

========

C is the intended answer in the legacy SMC question bank, but this item contains an important conflict with the SBOK rule and should not be memorized without that qualification.

The SBOK change-management guidance states that requirements and Acceptance Criteria for User Stories completed in the current Sprint should not be altered retroactively. Specifically, the Scrum Master should prevent a completed User Story from being rejected merely because it fails newly changed requirements. Instead, the relevant Product Backlog Item should be revised to reflect the changed requirement and scheduled for a future Sprint.

Published versions of this legacy SMC practice item key C, which captures its intended notion that changed requirements belong in the Prioritized Product Backlog for later development. However, the phrase “deliverable is rejected on the basis of the changed requirements” is inconsistent with SBOK's explicit rule.

Therefore, for this historical exam item, C is the expected choice, but the technically correct SBOK principle is: evaluate current work against the original Acceptance Criteria and handle the changed requirement through a revised/new backlog item in a future Sprint.

Study Guide reference: Change - > Managing Changes During a Sprint; Acceptance Criteria Stability; Refine Prioritized Product Backlog.

========

Create Sprint Backlog belongs to the Plan and Estimate phase, not the Implement phase.

In the terminology of this question's SBOK edition, the Implement phase consists of:

- Create Deliverables

- Conduct Daily Standup

- Groom Prioritized Product Backlog

Current SCRUMstudy terminology renames the third process Refine Prioritized Product Backlog, but it remains part of Implement.

Sprint Backlog creation occurs during planning after User Stories have been estimated and committed and tasks have been identified and estimated. The Sprint Backlog represents the work selected and structured for execution during the forthcoming Sprint.

Once implementation begins, the Scrum Team works through Sprint Backlog tasks to create deliverables, synchronizes through Daily Standups, and maintains the overall Prioritized Product Backlog through refinement activities.

Therefore, Create Sprint Backlog is the only listed process outside the Implement phase.

Study Guide reference: Plan and Estimate - > Create/Update Sprint Backlog; Implement - > Create Deliverables, Conduct Daily Standup, Groom/Refine Prioritized Product Backlog.

========

SBOK uses a standardized User Story structure that captures three fundamental dimensions of a requirement: Who, What, and Why. The prescribed format is:

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

The role/persona identifies the person or user group receiving value. The requirement identifies the capability needed. The benefit explains the business or user value produced by satisfying that requirement. Keeping this order helps ensure that the team does not treat a backlog item merely as a technical specification; instead, the requirement remains connected to the stakeholder who needs it and to the reason it creates value.

Options B, C, and D rearrange these components and therefore do not conform to the standard SBOK User Story template.

This structure also improves communication and estimation because Product Owners, Scrum Team members, and stakeholders can discuss the requirement in a compact, user-oriented format.

Study Guide reference: Plan and Estimate - > Create User Stories - > User Story Template; Personas; User Story Acceptance Criteria.

========

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

========

Statements I and II correctly describe how the Scrum Core Team can originate proposed changes. SBOK explains that ongoing interaction among the Product Owner, Scrum Master, Scrum Team, and stakeholders may lead Scrum Core Team members to suggest changes or product improvements. Recommendations commonly arise while creating deliverables, during Daily Standups, and particularly through the Retrospect Sprint process.

Statement IV is incorrect because the Scrum Master does not finalize formal Change Requests. The Product Owner has the decision authority to determine which suggested changes should become formal Change Requests and how approved changes should be prioritized in the Prioritized Product Backlog.

Statement III is not the applicable SBOK responsibility in the form stated here. Escalation beyond defined tolerances can involve other organizational authorities, but that does not make the Scrum Master the authority for finalizing or approving the change.

Thus, the technically supported statements are I and II. This also reinforces Scrum's separation between proposing/facilitating change and business prioritization/approval.

Study Guide reference: Change - > Change Requests - > Scrum Core Team; Retrospect Sprint; Product Owner authority over Prioritized Product Backlog.

========