Free Practice Questions for Scrum SMC Exam

The Daily Standup is a highly focused, time-boxed synchronization meeting for Scrum Team members. Members normally communicate what they completed, what they intend to do next, and what impediments are affecting their work. Every team member's participation supports transparency, coordination, collective ownership, and self-organization.

Option B directly conflicts with these principles. Inexperience does not justify excluding Scrum Team members. Less-experienced participants need visibility into the team's work just as much as experienced members and may require collaboration or assistance from colleagues. Exclusion would reduce transparency and weaken the team's collective responsibility.

Option A corresponds to discussing planned work. Option C corresponds to reporting progress since the previous meeting. Option D identifies an external environmental impediment—the distracting noise—which is appropriate to surface. The Daily Standup is not intended to become a lengthy problem-solving session, but impediments should be identified there and addressed subsequently, often with Scrum Master facilitation.

The Scrum Master therefore should reject the proposition that particular Scrum Team members need not attend merely because colleagues consider them inexperienced.

Study Guide reference: Implement - > Conduct Daily Standup; Organization - > Self-organizing Scrum Team; Scrum Master - > Impediment removal.

========

Option C reverses the actual Scrum-versus-traditional distinction. In Scrum, Return on Investment and business value can begin early and continue throughout the project lifecycle because potentially valuable increments are produced iteratively. Traditional sequential projects frequently defer realization of substantial value until the completed product is delivered. SCRUMstudy's comparison explicitly lists Scrum ROI as “early/throughout project life” and traditional ROI as occurring at the end of project life.

The other statements correctly reflect SBOK's comparison. Scrum organizations are self-organized rather than centrally managed. Scrum places greater emphasis on people and collaborative responsibility, whereas traditional management generally emphasizes formally defined processes. Scrum's quality philosophy is customer-centric and centered on delivering working outcomes that satisfy customer requirements and Acceptance Criteria, whereas traditional approaches are described as more process-centric.

Therefore, C is not merely a subtle difference—it states the ROI relationship in exactly the opposite direction.

Study Guide reference: Introduction to Scrum/Business Justification - > Scrum versus Traditional Project Management; Value-driven Delivery.

========

Done Criteria establish the common quality conditions that apply across User Stories and provide a consistent basis for determining whether work is complete. The SBOK framework identifies activities such as completed unit testing, completed documentation, quality-assurance activities, peer review, resolution of issues, and successful demonstrations as legitimate examples of Done Criteria.

The critical distinction in this question is statement I. A list of issues to be fixed means unresolved work remains. That is different from the SBOK concept that all relevant issues are fixed before the item satisfies the Done Criteria. Therefore, simply maintaining a list of outstanding problems cannot itself establish completion.

Unit testing is directly associated with confirming technical quality. Documentation may be required to satisfy organizational, regulatory, operational, or support requirements. Demonstration to stakeholders or business representatives can also form part of the general completion conditions established for the project. Consequently, statements II, III, and IV are appropriate, while statement I is not properly worded as a completion condition.

Study Guide reference: Quality - > Done Criteria; Create Prioritized Product Backlog - > establishment of Done Criteria; distinction between Done Criteria and User Story Acceptance Criteria.

========

The Prioritized Product Backlog is based primarily on value, risk or uncertainty, and dependencies. SCRUMstudy explicitly identifies these three factors when explaining the structure and prioritization of the backlog.

Value represents the business benefit expected from delivering the functionality. Higher-value items may be prioritized earlier so that useful business outcomes begin to accrue sooner. Risk and uncertainty are considered because addressing uncertain or high-risk work earlier can expose assumptions, enable mitigation, and prevent late discovery of critical problems. Dependencies influence sequencing because some requirements cannot be effectively developed before prerequisite functionality is available.

“Deliverables” are results produced through execution of backlog items; they are not one of the three primary prioritization factors specified in the SBOK model.

The combination of value, risk, and dependencies reflects Scrum's broader principles of value-based prioritization and adaptive planning. Prioritization is therefore more sophisticated than merely ordering requirements by desired functionality.

Consequently, statements I, II, and III are correct.

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

========

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.

========

The technically relevant principle is that business justification must be reassessed whenever major issues or risks threaten viability, making D the intended answer. SBOK states that business justification is initially assessed before project initiation and continuously verified throughout the lifecycle. Verification occurs at predefined intervals or milestones and also whenever significant issues or risks arise that could undermine the rationale for continuing the investment.

Option C overstates “continuous” by interpreting it as literal day-to-day formal review. Continuous Value Justification means that viability remains subject to ongoing validation; it does not require a complete business-case reassessment every working day. Option A is too late because justification must be maintained while investment decisions can still be changed. Option B imposes an every-Sprint portfolio review requirement that SBOK does not establish universally.

The question's repeated use of “portfolio business justification” is imperfectly aligned with the opening reference to a Product Owner. Strictly, project-level business justification is owned primarily by the Product Owner, while portfolio-level justification belongs to the Portfolio Product Owner. Nevertheless, the substantive business-justification trigger described in D is correct.

Study Guide reference: Business Justification - > Continuous Value Justification; Project Viability; Major Issues and Risks.

========

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.

========

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.

========

Ownership of grooming—or in current terminology, refining—the Prioritized Product Backlog belongs primarily to the Product Owner, not the Scrum Master. SCRUMstudy explicitly states that the Product Owner leads backlog refinement, adds or revises User Stories, reprioritizes work, and ensures upcoming requirements are sufficiently refined.

The Scrum Master may facilitate Prioritized Product Backlog Review Meetings and help ensure that communication, estimation, and Scrum practices remain effective, but facilitation is not the same as owning or grooming the backlog.

The Scrum Master also coordinates creation of the Release Planning Schedule as part of Conduct Release Planning. SCRUMstudy's role mapping explicitly lists that responsibility.

Similarly, the Scrum Master can represent Scrum Core Team experience and lessons learned so that organizational knowledge and Scrum Guidance Body recommendations can improve.

The critical distinction is between facilitating backlog refinement and being accountable for the contents and prioritization of the backlog. The latter belongs to the Product Owner.

Therefore, A is the activity that is not a Scrum Master responsibility.

Study Guide reference: Organization - > Scrum Master Responsibilities; Implement - > Groom/Refine Prioritized Product Backlog.

========