Scrum SMC - Scrum Master Certified (SMC)

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.

========

Statement B is false because task creation, decomposition, estimation, and execution belong fundamentally to the Scrum Team, not to the Product Owner.

SCRUMstudy states that the Task List contains tasks associated with the committed User Stories and that it must include relevant testing and integration work. The level of decomposition or granularity is also determined by the Scrum Team.

Testing and integration are necessary because the increment created during the current Sprint must integrate successfully with deliverables produced in earlier Sprints. This makes statements A and C valid.

Statement D is likewise consistent with self-organization. Those performing the work are best positioned to determine how a User Story should be decomposed technically and how much detail is required for effective execution.

The Product Owner clarifies requirements and Acceptance Criteria but does not assign or commit individual implementation tasks on behalf of team members. During Sprint Planning, the self-organizing Scrum Team determines how to accomplish committed User Stories.

Therefore, B incorrectly transfers task commitment authority to the Product Owner.

Study Guide reference: Plan and Estimate - > Identify/Create Tasks; Estimate Tasks - > Task List and Team Ownership.

========

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.

========

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.

========

A Sprint Burndown Chart graphically represents the amount of work that remains to be completed during an ongoing Sprint. SCRUMstudy's SBOK glossary explicitly defines it as a graph depicting the amount of work remaining in the Sprint.

Normally, the horizontal axis represents elapsed Sprint time and the vertical axis represents remaining effort, tasks, or points. As work is completed, the plotted remaining workload should trend downward toward zero. Comparing actual remaining work with an expected trajectory helps the Scrum Team identify whether progress is broadly consistent with the Sprint plan.

Option A relates more directly to the Impediment Log and Daily Standup discussions. Although a Burndown Chart may indirectly indicate that progress has slowed, it does not identify the specific impediment causing that condition. Option C describes completed work rather than the traditional burndown representation of remaining work. Option D describes task or User Story estimation rather than Sprint tracking.

Therefore, its fundamental purpose is to visualize work remaining during the Sprint.

Study Guide reference: Implement - > Sprint Tracking Tools - > Sprint Burndown Chart.

========

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.

========

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.

========

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.

========

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.

========

Option B is incorrect because responsibility for communicating and clarifying prioritized User Stories fundamentally rests with the Product Owner, not with the Scrum Master. SCRUMstudy states that Acceptance Criteria are developed by the Product Owner according to the Product Owner's understanding of customer requirements, after which the Product Owner communicates the User Stories to Scrum Team members and seeks their agreement.

The Scrum Master facilitates the process and helps ensure effective collaboration, but does not replace the Product Owner as the Voice of the Customer or primary source of business-requirement clarification.

Option A is therefore correct: the Product Owner develops Acceptance Criteria using customer requirements. Option C is also correct because the Scrum Team's agreement is sought when User Stories are communicated and prepared for Sprint work.

Option D reflects the acceptance mechanism: at Sprint review/validation, the Product Owner verifies completed work against the agreed Acceptance Criteria. When the deliverable satisfies the relevant criteria and is accepted, the associated User Story is considered Done.

Study Guide reference: Plan and Estimate - > Create User Stories/Acceptance Criteria; Quality - > Acceptance and Done; Product Owner responsibilities.

========

Page

Scrum Master Certified (SMC®) — 100 Questions