Free Practice Questions for Scrum SMC Exam

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.

========

Story points are a relative estimation unit, not a direct representation of elapsed hours. They allow the Scrum Team to compare the overall size of User Stories by considering characteristics such as effort, complexity, uncertainty, and risk.

SCRUMstudy states that Relative Sizing/Story Points assigns a point value according to the overall size of a User Story, considering factors including the effort required and level of complexity. Once one item has been estimated, other User Stories can be estimated relative to that reference item.

Option A incorrectly equates story points with hours. Scrum can use time-based task estimates, but story points intentionally support relative rather than absolute estimation. Option C describes a count of completed stories rather than story points. Option D incorrectly assigns estimation responsibility to the Product Owner. Estimation is performed by the Scrum Team, because those performing the work are best positioned to judge its technical complexity and effort.

Story points consequently support velocity measurement and future forecasting without pretending that complex knowledge work can always be predicted precisely in hours.

Study Guide reference: Plan and Estimate - > Estimate User Stories - > Relative Sizing/Story Points.

========

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.

========

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.

========

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.

========

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.

========

An Epic represents a high-level requirement that is generally too large or insufficiently detailed to be completed as a single User Story within one Sprint. As an Epic rises in priority and approaches implementation, it is progressively elaborated and decomposed into smaller User Stories.

SCRUMstudy explicitly states that some Epics/User Stories are initially too large to handle within one Sprint and are therefore broken into smaller User Stories when they move high enough in the Prioritized Product Backlog to be considered for upcoming Sprint work.

Smaller User Stories improve estimation, clarification, testability, and the team's ability to create potentially shippable increments within the Sprint time-box. They also enable the Product Owner to prioritize individual pieces of functionality according to value rather than treating a large requirement as one indivisible block.

Option A may be an indirect benefit but is not the fundamental reason. Team size does not determine whether an Epic must be decomposed, and review duration is not the defining criterion.

Therefore, the correct answer is that Epics are too large to be completed within a single Sprint.

Study Guide reference: Plan and Estimate - > Create User Stories - > Decomposition of Epics.

========

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.

========

A risk threshold identifies the point or level at which exposure changes from being acceptable to unacceptable. SCRUMstudy distinguishes risk threshold from the related concepts of risk appetite and risk tolerance. Risk appetite reflects the overall amount of uncertainty an organization is willing to pursue or accept, while risk tolerance describes the degree or volume of variation the stakeholder can withstand. The threshold establishes the boundary at which action or rejection becomes necessary.

In this scenario, some defects remain acceptable and do not prevent release. Once the defect level rises beyond a specified point, however, the deliverables will be rejected. This establishes a clear acceptance boundary, making it a textbook example of a risk threshold.

Risk seeking is a behavioral attitude in which a stakeholder is willing to accept greater uncertainty in pursuit of additional benefits. That concept does not apply here.

The decisive phrase is effectively “acceptable until this level is exceeded.” Once that boundary is crossed, the response changes. Therefore, the scenario illustrates Risk Threshold.

Study Guide reference: Risk - > Risk Attitude - > Risk Appetite, Risk Tolerance, Risk Threshold, Utility Function.

========

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.

========