Free Scrum SMC Practice Exam with Questions & Answers

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.

========

The Scrum Master facilitates planning rather than performing the team's estimates. Consequently, acting as the moderator and impediment remover is the correct responsibility.

During task estimation, the Scrum Team determines the effort necessary to accomplish tasks associated with committed User Stories. The resulting Effort Estimated Task List provides the estimated work associated with Sprint tasks and supports creation or updating of the Sprint Backlog. SCRUMstudy confirms that task estimation is performed by the Scrum Team and that the Scrum Master supports and facilitates the relevant meetings rather than imposing estimates.

Option B is not the objective of Scrum Master facilitation; diverse perspectives can naturally emerge, but they are not something the Scrum Master artificially ensures. Option C incorrectly suggests that the Scrum Master determines how tasks should be decomposed or estimated. That authority rests with the self-organizing Scrum Team. Option D is logically defective and reflects an obvious wording problem in the supplied question.

The Scrum Master therefore enables effective planning by maintaining the process, facilitating discussion, removing obstacles, and ensuring that the team—not the facilitator—owns the estimates.

Study Guide reference: Plan and Estimate - > Estimate Tasks - > Effort Estimated Task List; Sprint Planning Meeting; Scrum Master facilitation.

========

Scrum deliberately creates opportunities to learn from mistakes rather than treating every problem as a failure requiring blame. The Retrospect Sprint and Retrospect Project processes institutionalize this continuous-learning mechanism.

During a Retrospect Sprint Meeting, the Scrum Team examines what went well, what did not go well, and what should change during subsequent Sprints. The main outcome is a set of actionable improvements intended to enhance future performance.

Retrospect Project extends the same principle across the complete project and captures broader lessons so they can benefit future teams and projects.

This helps inexperienced teams understand that uncertainty, errors, and imperfect forecasts are expected in empirical product development. Scrum provides repeated opportunities to inspect outcomes and adapt processes rather than demanding perfect prediction at the outset.

Sprint Planning and backlog creation are necessary planning activities, but they do not directly address fear of mistakes. Time-boxing limits exposure but does not provide the structured learning mechanism described.

Therefore, D is the most appropriate answer.

Study Guide reference: Review and Retrospect - > Retrospect Sprint; Release - > Retrospect Project; Continuous Improvement.

========

Velocity measures the amount of estimated work successfully completed by a Scrum Team during a Sprint. Where User Stories are estimated in story points, Sprint velocity is normally calculated by totaling the story-point values of the User Stories completed during that Sprint. SCRUMstudy explicitly describes velocity in these terms.

Velocity is particularly useful because historical values can support future Sprint planning and release forecasting. After several Sprints, a reasonably stable team can use its observed velocity to estimate how much work it is realistically capable of completing in a similar Sprint.

Business Value Delivered measures value rather than effort points. Number of Stories counts items without considering their relative size—a Sprint containing five small stories is not necessarily equivalent to one containing five large stories. A Sprint Burndown Chart shows remaining work over time during the Sprint rather than defining the quantity of story points successfully delivered.

Therefore, the metric that directly captures the number of completed story points per Sprint is Velocity.

Study Guide reference: Plan and Estimate - > Estimation; Implement - > Sprint Metrics; Velocity and Story Points.

========

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.

========

Earned Value Analysis (EVA) does not primarily increase awareness of the components, activities, and development sequence of a product. EVA is fundamentally a performance-measurement technique that compares planned value, earned value, and actual cost to assess cost and schedule performance.

By contrast, a Product Breakdown Structure decomposes the product into constituent components, increasing understanding of what must be created. A Work Breakdown Structure organizes the work required to create project outputs, improving awareness of activities and relationships. A Product Flow Diagram illustrates the sequence in which product components are created or integrated.

These techniques support the awareness dimension of collaboration because team members can understand what work exists, how components relate, and how activities interact. SBOK defines collaboration in terms of awareness, articulation, and appropriation, with awareness involving knowledge of one another's work and the overall project environment.

Earned Value Analysis instead measures performance against a baseline and therefore does not directly perform the structural or workflow-visualization function described in the question.

Study Guide reference: Principles - > Collaboration - > Awareness; project/product visualization techniques.

========

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 deliverable does not become Accepted merely because the Scrum Team believes development is complete. Formal acceptance occurs when the Product Owner evaluates the deliverable against the agreed User Story Acceptance Criteria and accepts the associated User Story.

SCRUMstudy states that Acceptance Criteria are objective conditions used to judge User Story functionality. At the end of a Sprint, the Product Owner uses those criteria to verify completed deliverables and either accepts or rejects them. When accepted, the corresponding User Story is considered Done.

Option A lacks Product Owner validation. Option C reflects a team's assessment that work may be potentially shippable, but that does not independently constitute formal acceptance. Option D addresses internal testing and quality verification, which are necessary components of producing Done work but are insufficient by themselves to create an Accepted Deliverable.

This distinction separates technical completion from business acceptance. The Scrum Team builds and verifies the increment; the Product Owner determines whether the agreed business conditions have been fulfilled.

Therefore, B provides the correct definition.

Study Guide reference: Review and Retrospect - > Demonstrate and Validate Sprint - > Accepted Deliverables; Quality - > Acceptance Criteria.

========

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

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.

========