Free Scrum SMC Practice Exam with Questions & Answers | Set: 3

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

========

Successful release depends fundamentally on the Scrum Team creating the agreed deliverables so that completed and accepted work can eventually be transitioned to the customer or other relevant business stakeholders. The Release phase's Ship Deliverables process handles accepted deliverables, while the Product Owner coordinates deployment with the customer.

Option B describes activities associated with the Product Owner following validation and backlog/release-plan management rather than the specific condition the Scrum Master must ensure for successful creation of releasable work.

Option C is incorrect because the Release Planning Schedule is developed during Conduct Release Planning, involving the Product Owner and Scrum Core Team; it is not simply created by the Scrum Team during Ship Deliverables.

Option D incorrectly assigns acceptance authority. During Demonstrate and Validate Sprint, the Product Owner, not the Scrum Team, accepts or rejects completed User Stories against their Acceptance Criteria.

Therefore, ensuring that the Scrum Team creates the committed deliverables as agreed provides the necessary basis for later acceptance and release.

Study Guide reference: Release - > Ship Deliverables; Implement - > Create Deliverables; Review and Retrospect - > Demonstrate and Validate Sprint.

========

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.

========

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 deliverable that fails its User Story Acceptance Criteria is a Rejected Deliverable. It is not marked Done and normally returns to, or remains in, the Prioritized Product Backlog where it can be reprioritized and completed during a future Sprint. SCRUMstudy explicitly states that rejected User Stories are added back to the updated backlog for future Sprints.

Option A is therefore false because future correction is specifically permitted and expected when necessary. Option B incorrectly states that the Scrum Master defines Acceptance Criteria. They are primarily defined by the Product Owner based on customer requirements. Option D is incorrect because the objective is not to create increments that may satisfy Acceptance Criteria; completed deliverables should satisfy the applicable criteria before acceptance.

Carrying rejected work into a later Sprint is undesirable because the aim is to create potentially shippable, acceptable results during each Sprint, but Scrum provides a clear mechanism for managing such incomplete work.

Therefore, C accurately describes the handling of a rejected deliverable.

Study Guide reference: Review and Retrospect - > Demonstrate and Validate Sprint - > Accepted and Rejected Deliverables.

========

The standard SBOK User Story format is:

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

A User Story therefore expresses three essential dimensions: Who, What, and Why. The “Why” component identifies the benefit or value expected from satisfying the requirement.

Option D directly corresponds to that third component: What benefit is expected from the requirement? This helps ensure that functionality is connected to user or business value rather than being treated simply as an isolated technical request.

Cost of development is addressed through estimation and business-justification activities rather than the core User Story template. The specific individual responsible for performing the work is not embedded in a User Story because Scrum Teams are self-organizing and determine task ownership during planning and execution. Testing techniques may influence tasks or Acceptance Criteria but are not one of the three core User Story template elements.

Therefore, the expected benefit is the relevant question.

Study Guide reference: Plan and Estimate - > Create User Stories - > User Story Template: Role/Persona, Requirement, Benefit.

========

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.

========

The Scrum Team determines how prioritized requirements are transformed into completed deliverables. This is a direct consequence of Scrum's principle of self-organization.

SBOK states that Scrum Team members possess both the authority and responsibility to determine the best means of converting Prioritized Product Backlog Items into finished deliverables without requiring business stakeholder involvement in those technical implementation decisions.

The Product Owner determines what should be built and prioritizes requirements according to value, risk, dependencies, and stakeholder needs. The Scrum Team determines how committed functionality will actually be designed, developed, integrated, tested, and completed.

The Scrum Master facilitates the team's work, removes impediments, coaches participants, and protects Scrum processes but does not dictate implementation. Stakeholders supply business needs and feedback but similarly do not control technical execution.

This separation of responsibilities is fundamental to Scrum: business priorities are represented by the Product Owner, process effectiveness is supported by the Scrum Master, and technical/product-delivery decisions are made by the self-organizing Scrum Team.

Therefore, D is correct.

Study Guide reference: Organization - > Scrum Team Responsibilities; Principles - > Self-organization.

========

The Daily Standup is a synchronization and transparency mechanism, not an individual performance-management meeting. Team members discuss recent progress, upcoming work, and impediments so that the self-organizing Scrum Team can coordinate effectively and identify problems requiring follow-up.

SCRUMstudy describes Daily Standups as providing team members with visibility into strengths, weaknesses, missed tasks, dependencies, and impediments so that the team can collaboratively adjust its work.

Detailed problem solving is normally kept outside the tightly time-boxed meeting. An impediment raised during the Standup can subsequently be investigated and resolved with Scrum Master support. Information about recurring difficulties can also contribute to subsequent Sprint improvement discussions and retrospective learning.

Using the meeting to track individual employee performance, however, would undermine self-organization and encourage reporting upward to a manager rather than communication among peers. Scrum evaluates progress primarily at the team and deliverable level.

Therefore, individual performance tracking is specifically the inappropriate use of Daily Standup information.

Study Guide reference: Implement - > Conduct Daily Standup; Principles - > Self-organization and Collaboration.

========