Scrum SMC Scrum Master Certified (SMC) Exam Practice Test

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.

========

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.

========

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.

========

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.

========

The Scrum Master facilitates the identification, assessment, communication, and escalation of problems and Change Requests generated by the Scrum Team. The Product Owner then evaluates business impact and determines how approved changes should be prioritized within the Prioritized Product Backlog. This separation preserves both facilitation and business accountability.

Option A is contrary to Scrum. Scrum does not attempt to eliminate change; it deliberately accommodates change while maintaining stability during the active Sprint.

Option C is primarily a Product Owner/business stakeholder responsibility when interpreted as formally submitting project changes. Scrum Team members and the Scrum Master may suggest improvements, but the Scrum Master's principal defined change-management responsibility is facilitation, not ownership of business Change Requests.

Option D incorrectly gives approval authority to the Scrum Master. Formal change approval and prioritization are driven by the Product Owner within organizational tolerance levels and applicable Scrum Guidance Body procedures.

Consequently, B accurately reflects the Scrum Master's servant-leadership role: enabling the Scrum Team to surface necessary changes and ensuring that those changes reach the appropriate Product Owner decision process.

Study Guide reference: Change - > Summary of Responsibilities Relevant to Change; Change Requests; Product Owner prioritization.

========

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.

========

SBOK addresses this under Confirm Benefits Realization. Scrum projects must verify throughout their lifecycle that the deliverables being created are actually capable of producing the benefits and business value identified at project initiation. One of the principal confirmation techniques is to demonstrate prototypes to customers and simulate their functionality.

This allows customers and users to interact with, observe, or evaluate a representation of the intended solution. They can determine whether functionality is adequate, whether requirements were interpreted correctly, and whether modifications or additional capabilities are necessary. SCRUMstudy specifically identifies prototypes, simulations, workshops, and demonstrations as benefit-confirmation mechanisms.

Option B describes brainstorming, particularly a risk-identification technique. Option C resembles a risk-based spike, which is an experiment or prototype used to investigate uncertainty or risk rather than directly confirm project benefits. Option D resembles subjective prioritization or risk-analysis techniques.

Therefore, demonstrating prototypes and simulated functionality is the direct SBOK technique for confirming value and expected benefits.

Study Guide reference: Business Justification - > Confirm Benefits Realization - > Prototypes, Simulations, and Demonstrations.

========

The Release Planning Meeting is associated with the Initiate phase, specifically the Conduct Release Planning process. It is therefore not an Implement-phase activity.

SCRUMstudy identifies three Implement processes: Create Deliverables, Conduct Daily Standup, and Refine Prioritized Product Backlog. During Create Deliverables, the team executes Sprint Backlog tasks. Conduct Daily Standup provides daily synchronization and impediment identification. Refine Prioritized Product Backlog continually updates and maintains the project's backlog as new information, requirements, risks, and changes emerge.

Option B uses the wording “Updating the Product Backlog,” which corresponds to the refinement process and is therefore part of Implement. Option A directly represents Conduct Daily Standup, while D directly represents Create Deliverables.

Release Planning instead establishes the release schedule, planned delivery intervals, and Sprint length at the project-initiation level, though the schedule can later be updated as conditions evolve.

Consequently, C is the activity not executed as an Implement process.

Study Guide reference: Implement - > Create Deliverables, Conduct Daily Standup, Refine Prioritized Product Backlog; Initiate - > Conduct Release Planning.

========

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.

========

SBOK establishes a specific exception to the general rule that Sprint scope remains unchanged once implementation begins. If the Scrum Team determines that it has significantly overestimated the effort required and consequently has genuine spare capacity, the team may ask the Product Owner which additional User Stories can be introduced into the current Sprint.

The Sprint Backlog and Sprint Burndown/Burnup information can make this situation visible by showing that work is being completed considerably faster than expected and that meaningful capacity remains.

Option A is insufficient because having highly skilled individuals does not itself authorize scope modification. Option B is also insufficient: one idle member does not necessarily mean the overall Scrum Team has enough capacity to complete another User Story. Option C concerns potential future Change Requests and provides no justification for disturbing the current Sprint.

The exception therefore applies when the team as a whole has overestimated effort and has spare capacity. Even then, the Scrum Team does not unilaterally select new work; it asks the Product Owner which additional prioritized User Story should be included.

Study Guide reference: Change - > Changes to a Sprint - > Exception for Overestimated Effort and Spare Capacity.

========

Page

Scrum Master Certified (SMC®) — 100 Questions

Statements I and II correctly describe how the Scrum Core Team can originate proposed changes. SBOK explains that ongoing interaction among the Product Owner, Scrum Master, Scrum Team, and stakeholders may lead Scrum Core Team members to suggest changes or product improvements. Recommendations commonly arise while creating deliverables, during Daily Standups, and particularly through the Retrospect Sprint process.

Statement IV is incorrect because the Scrum Master does not finalize formal Change Requests. The Product Owner has the decision authority to determine which suggested changes should become formal Change Requests and how approved changes should be prioritized in the Prioritized Product Backlog.

Statement III is not the applicable SBOK responsibility in the form stated here. Escalation beyond defined tolerances can involve other organizational authorities, but that does not make the Scrum Master the authority for finalizing or approving the change.

Thus, the technically supported statements are I and II. This also reinforces Scrum's separation between proposing/facilitating change and business prioritization/approval.

Study Guide reference: Change - > Change Requests - > Scrum Core Team; Retrospect Sprint; Product Owner authority over Prioritized Product Backlog.

========

The Create Deliverables process is an Implement-phase activity in which the Scrum Team executes the tasks contained in the Sprint Backlog and creates the Sprint Deliverables. SCRUMstudy describes this process as the team working on Sprint Backlog tasks to produce deliverables while using mechanisms such as the Scrumboard and Impediment Log to manage execution.

Options A, C, and D can represent tangible or project-specific results produced through Sprint execution. Construction work, an updated engineering blueprint, and completed seismic retrofit work can each constitute deliverables when they correspond to committed Sprint Backlog items and satisfy the applicable Done Criteria.

Raw materials acquired for the next Sprint, however, represent preparation or resource procurement for future work rather than a deliverable generated from execution of the current Sprint Backlog. The defining output of Create Deliverables is completed work resulting from the current Sprint's committed tasks, not inventory accumulated for subsequent iterations.

Therefore, B is the exception.

Study Guide reference: Implement - > Create Deliverables - > Sprint Backlog execution, Sprint Deliverables, Scrumboard, Impediment Log.

========

The description corresponds to the Scrum Guidance Body (SGB). The SGB can provide organizational guidance, standards, regulations, recommended practices, templates, procedures, and lessons learned that Scrum Core Teams may use when appropriate.

In the backlog-refinement context, Scrum Guidance Body Recommendations can include guidance on how to understand and collate requirements, prioritize the backlog, document User Stories appropriately, and communicate changes to relevant participants.

Subject Matter Experts provide specialized knowledge based on particular technical or business domains, but the question specifically refers to documented organizational rules, development guidelines, standards, and best practices, which are characteristic of the Scrum Guidance Body.

Team Expertise refers to the collective capability of Scrum Team members to understand and execute Sprint work. Stakeholders contribute requirements, business needs, feedback, and priorities, but they are not the repository responsible for organizational Scrum standards.

The Scrum Guidance Body therefore provides consistency without converting Scrum into a centralized command-and-control methodology. Its recommendations support teams while still allowing appropriate tailoring.

Study Guide reference: Implement - > Groom/Refine Prioritized Product Backlog - > Scrum Guidance Body Recommendations.

========

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.

========

Within the SBOK quality framework, the Scrum Master is responsible for facilitating a quality-oriented environment, eliminating environmental impediments, maintaining a sustainable pace, and ensuring that Scrum processes are correctly followed by all members, including the Product Owner. Therefore, option C directly corresponds to the Scrum Master's defined quality responsibilities.

Option A belongs primarily to the Product Owner. During Demonstrate and Validate Sprint, the Product Owner evaluates completed work against the User Story Acceptance Criteria and accepts or rejects the relevant User Stories or deliverables. Option B is associated with the Scrum Guidance Body, which may establish organizational standards, quality guidance, and the acceptable range of tools or practices. Option D belongs to the Scrum Team, which performs the development work and makes the technical changes necessary to create compliant deliverables.

This division of accountability is central to SMC role questions. The Scrum Master facilitates and protects the process but does not act as a conventional project manager or technical supervisor. The Product Owner protects value and acceptance, while the Scrum Team determines how the work is executed.

Study Guide reference: Quality - > Summary of Responsibilities Relevant to Quality; Organization - > Scrum Master role.

========

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.

========

Statement B is inaccurate because SBOK risk management operates across project, program, and portfolio levels. A risk may originate at the program or portfolio level yet affect one or more projects. In such circumstances, information about that risk must be communicated to the affected Product Owner and Scrum Team, while the risk can continue to be managed at the level where it originated. Serious portfolio/program risks can even cause a project team to reconsider or re-plan Sprint work.

Scrum's iterative structure also reduces exposure by creating short feedback cycles. Problems become visible sooner than in long sequential delivery models, allowing corrective action before excessive investment accumulates. Risk information can be communicated through artifacts such as Risk Burndown Charts.

Scrum's flexibility further assists risk management because approved changes can be incorporated into the Prioritized Product Backlog and prioritized for subsequent Sprints. This does not mean uncontrolled scope changes are introduced into an active Sprint; Sprint stability remains protected.

Therefore, the assertion that risks can only be managed at project level directly contradicts SBOK's treatment of program- and portfolio-level risk.

Study Guide reference: Risk - > Risks in Portfolios and Programs; Risk Identification, Assessment, Prioritization, and Communication.

========

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

========

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.

========

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.

========

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.

========

The Initiate phase establishes the foundation of the Scrum project. SCRUMstudy identifies its processes as Create Project Vision, Identify Scrum Master and Business Stakeholder(s), Form Scrum Team, Develop Epic(s), Create Prioritized Product Backlog, and Conduct Release Planning. Therefore, identifying the Scrum Master and relevant stakeholders is explicitly an Initiate-phase activity.

The remaining options belong to later phases. Estimating and committing User Stories form part of Plan and Estimate, where requirements selected from the Prioritized Product Backlog are analyzed, estimated, and committed for upcoming Sprint work. Conduct Daily Standup belongs to Implement, because it occurs while the Scrum Team is executing Sprint work and synchronizing daily activities.

This phase separation is important in SMC questions. Initiate establishes the vision, roles, high-level requirements, prioritized backlog, and initial release structure. Plan and Estimate converts prioritized requirements into executable Sprint-level work. Implement concerns actual creation of deliverables and daily coordination.

Accordingly, Identify Scrum Master and Stakeholder(s) is the only option that is explicitly part of the Initiate phase.

Study Guide reference: Initiate - > Identify Scrum Master and Business Stakeholder(s); Plan and Estimate - > Estimate/Commit User Stories; Implement - > Conduct Daily Standup.

========

Acceptance Criteria are the objective conditions by which the functionality of a User Story is judged. They enable the Product Owner to determine whether the completed deliverable satisfies the agreed requirement and whether the associated User Story can be accepted as Done. SCRUMstudy specifically emphasizes the objectivity of Acceptance Criteria and the Product Owner's authority to accept or reject work against them.

Option C is incorrect because Acceptance Criteria are defined primarily by the Product Owner, based on understanding of customer requirements. The Scrum Master facilitates Scrum and protects the integrity of the Sprint but does not own those business acceptance conditions.

Option D places acceptance in the wrong meeting. Acceptance occurs during Demonstrate and Validate Sprint/Sprint Review, not during Retrospect Sprint. The retrospective concerns lessons learned and process improvement.

Option A similarly confuses activities and meetings.

Therefore, the core purpose of Acceptance Criteria is to provide measurable, objective conditions against which a User Story can be judged Done or not Done.

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

========

Statements II and IV are correct.

SBOK describes the Retrospect Project Meeting as a forum where the project participants examine positives, negatives, and potential opportunities for improvement. The meeting also explicitly captures and documents lessons learned so that they can be internalized and applied to future projects.

Statement III is false because the Retrospect Project Meeting is not Time-boxed, although it may indeed be conducted physically or virtually. Because the statement combines one false and one true condition, the complete statement is false.

Statement I is not an accurate description of the principal meeting objective. Scrum Guidance Body recommendations may address mechanisms for maintaining organizational knowledge, but the Retrospect Project Meeting itself primarily examines overall project experience, team effectiveness, collaboration, lessons, and improvement opportunities.

This meeting differs from Retrospect Sprint in scope. Retrospect Sprint seeks improvements for subsequent Sprints within an ongoing project, whereas Retrospect Project captures broader learning after completion.

Therefore, statements II and IV are the supported pair.

Study Guide reference: Release - > Retrospect Project - > Retrospect Project Meeting and Lessons Learned.

========

The Prioritized Product Backlog is not listed as an input to the SBOK Conduct Daily Standup process. In the relevant SBOK process model, inputs include the Scrum Team, Scrum Master, Scrumboard, Impediment Log, Sprint Burndown/Burnup Chart, Product Owner, previous workday experience, and dependencies. The Product Owner is not mandatory for the meeting, but may contribute as an input to the process.

The Sprint Burndown Chart provides visibility into Sprint progress and remaining work. Dependencies may surface during the Daily Standup because they can create impediments or affect sequencing. The Product Owner may be available where clarification or business input is relevant, although the Daily Standup remains principally a Scrum Team synchronization forum.

The Prioritized Product Backlog is instead the overarching project requirements repository managed and refined through backlog processes. The active Sprint is driven by its Sprint Backlog, not by repeatedly replanning directly from the entire Prioritized Product Backlog each day.

Therefore, among the options presented, B is the exception.

Study Guide reference: Implement - > Conduct Daily Standup - > Inputs; distinction between Prioritized Product Backlog and Sprint execution artifacts.

========

The Prioritized Product Backlog is not a tool of the Create Deliverables process. In the legacy SBOK process structure underlying this question, the principal Create Deliverables tools include Team Expertise, Software, Other Development Tools, and Scrum Guidance Body Expertise. Other Development Tools may include techniques such as refactoring and Design Patterns.

Team Expertise represents the collective technical and functional knowledge used by Scrum Team members to transform Sprint work into finished deliverables. Software tools may support scheduling, collaboration, tracking, information distribution, and project execution. Design Patterns provide reusable approaches for resolving recurring design problems and can therefore support creation of deliverables.

The Prioritized Product Backlog serves a different function: it represents the prioritized project requirements maintained by the Product Owner. During the Sprint itself, the Scrum Team executes work from the Sprint Backlog, which contains the committed work for that Sprint.

Therefore, although the Prioritized Product Backlog ultimately drives what enters future Sprints, it is not classified as a Create Deliverables tool.

Study Guide reference: Implement - > Create Deliverables - > Inputs and Tools.

========

The intended answer is Continuous stakeholder involvement because it is not one of the specific SBOK characteristics listed for achieving flexibility.

SCRUMstudy identifies the principal mechanisms supporting flexibility as iterative product development, time-boxing, cross-functional teams, customer value-based prioritization, and continuous integration. These mechanisms allow Scrum projects to absorb changing business needs while protecting stability within an active Sprint.

Iterative development creates repeated opportunities to inspect outcomes and adjust requirements. Time-boxing constrains uncertainty and establishes predictable review intervals. Cross-functional teams reduce handoffs and external dependencies by containing the required skills within the team.

Stakeholder involvement is certainly important in Scrum and supports feedback, validation, and value realization. However, the question asks for the item that is not part of the specific enumerated SBOK list of characteristics used to explain flexibility. The formally listed concept is customer value-based prioritization rather than “continuous stakeholder involvement.”

This is therefore a terminology-sensitive SMC question: option C describes a useful Scrum practice, but it is not the designated characteristic in this particular SBOK framework.

Study Guide reference: Change - > Flexibility versus Stability; Principles - > Iterative Development and Time-boxing.

========

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.

========