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.

========

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.

========

Option C is false because User Story Acceptance Criteria are primarily defined by the Product Owner, based on the Product Owner's understanding of customer and business requirements. The Product Owner then communicates the User Stories and their criteria to the Scrum Team, and agreement and clarification are obtained. SCRUMstudy explicitly identifies Acceptance Criteria as objective conditions developed by the Product Owner.

The Scrum Master facilitates the process and ensures that agreed Acceptance Criteria are not inappropriately changed during an active Sprint, but the Scrum Master does not jointly own their definition with the Scrum Team.

Option D accurately reflects Scrum's iterative delivery approach: work is developed in short, time-boxed Sprints. Options A and B describe the more centralized quality and formal change-management characteristics typically associated with traditional project-management models in the SBOK comparison.

This distinction is important because Scrum incorporates quality continuously through Done Criteria, Acceptance Criteria, iterative development, inspection, adaptation, and frequent stakeholder feedback instead of treating quality primarily as a late project-control activity.

Study Guide reference: Quality - > Quality in Scrum versus Traditional Project Management; Acceptance Criteria; Product Owner Responsibilities.

========

Page

Scrum Master Certified (SMC®) — 100 Questions

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 SBOK framework identifies six Scrum principles: Empirical Process Control, Self-organization, Collaboration, Value-based Prioritization, Time-boxing, and Iterative Development. These principles are fundamental and apply across Scrum projects regardless of industry or product type.

Self-organization allows team members to determine how best to accomplish their work rather than relying on command-and-control assignment. Collaboration supports shared value creation and effective interaction among the Scrum Core Team and stakeholders. Value-based Prioritization ensures that higher-value requirements receive appropriate priority so that business value can begin to be delivered early.

Linear product delivery, however, is inconsistent with Scrum. Linear or sequential delivery is characteristic of approaches in which major project phases occur predominantly one after another. Scrum instead relies on short, repeated iterations in which work is planned, developed, reviewed, and adapted continuously.

Therefore, linear product delivery is not one of the Scrum principles.

Study Guide reference: Principles - > Six Scrum Principles - > Self-organization, Collaboration, Value-based Prioritization, Iterative Development.

========

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.

========

Within the SBOK framework reflected by this SMC question set, the recommended Scrum Team size is six to ten members. This range is intended to provide enough cross-functional capability to create the Sprint deliverables while keeping coordination and communication manageable.

If a team becomes too large, communication channels increase rapidly, meetings become more difficult to manage, self-organization becomes less efficient, and individual accountability can become diluted. Large projects are therefore normally handled through multiple Scrum Teams coordinated using mechanisms such as Scrum of Scrums rather than by constructing a single excessively large team.

Conversely, a very small team may not contain sufficient breadth of skills to function cross-functionally or may become vulnerable when one person is unavailable.

Therefore, among the choices presented, six to ten is the intended SBOK answer.

Study Guide reference: Organization - > Scrum Team - > Team Size and Personnel Selection; Scaling Scrum - > formation of multiple Scrum Teams for larger projects.

========

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 six non-negotiable Scrum principles:

1. Empirical Process Control

2. Self-organization

3. Collaboration

4. Value-based Prioritization

5. Time-boxing

6. Iterative Development

Collaboration is therefore a Scrum principle and focuses on awareness, articulation, appropriation, and shared value creation. Value-based Prioritization ensures that the project continuously focuses on work producing the greatest business value. Iterative Development allows teams to repeatedly build, inspect, obtain feedback, and adapt to changing requirements.

Manage by Stages is not an SBOK Scrum principle. It is terminology associated particularly with PRINCE2's project-management principles, where a project is planned, monitored, and controlled stage by stage.

Although Scrum does divide work into Sprints, this should not be confused with the “Manage by Stages” principle. Scrum Sprints are iterative, adaptive development cycles rather than traditional management stages.

Therefore, C is not one of SBOK's six Scrum principles.

Study Guide reference: Principles - > Six Scrum Principles.

========

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.

========