SMC Scrum Master Certified (SMC) Questions and Answers

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.

========

Once a Sprint begins, its committed scope and Acceptance Criteria are normally protected from change. New requirements are ordinarily added to the Prioritized Product Backlog and considered in a later Sprint. However, SBOK defines an important exception: if a change is so significant that continuing the existing Sprint would no longer create meaningful or useful results, the active Sprint should be terminated and a new Sprint planned using the revised requirements.

The scenario explicitly describes a critical business requirement that changes the Acceptance Criteria governing committed work. This implies that the existing Sprint outcome may no longer satisfy the customer's essential need. In that situation, simply continuing against obsolete criteria would waste resources.

Option A allows uncontrolled mid-Sprint scope substitution, which Scrum avoids. Option B would normally be correct for a non-urgent change, but the question emphasizes criticality. Option C incorrectly frames the problem as team bandwidth rather than Sprint stability and business value.

Therefore, where the changed requirement invalidates the current Sprint's intended outcome, Sprint termination and replanning is the appropriate response.

Study Guide reference: Change - > Integrating Change; Maintaining Sprint Stability; Managing Urgent Change Requests.

========

A Sprint Burndown Chart graphically represents the amount of work that remains to be completed during an ongoing Sprint. SCRUMstudy's SBOK glossary explicitly defines it as a graph depicting the amount of work remaining in the Sprint.

Normally, the horizontal axis represents elapsed Sprint time and the vertical axis represents remaining effort, tasks, or points. As work is completed, the plotted remaining workload should trend downward toward zero. Comparing actual remaining work with an expected trajectory helps the Scrum Team identify whether progress is broadly consistent with the Sprint plan.

Option A relates more directly to the Impediment Log and Daily Standup discussions. Although a Burndown Chart may indirectly indicate that progress has slowed, it does not identify the specific impediment causing that condition. Option C describes completed work rather than the traditional burndown representation of remaining work. Option D describes task or User Story estimation rather than Sprint tracking.

Therefore, its fundamental purpose is to visualize work remaining during the Sprint.

Study Guide reference: Implement - > Sprint Tracking Tools - > Sprint Burndown Chart.

========

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.

========

Scrum is especially valuable where requirements are uncertain, changing, innovative, or dependent on continuing stakeholder feedback. All three scenarios possess one or more of these characteristics.

Vault Safe involves a new and innovative product. Innovation normally brings technical uncertainty and evolving understanding, making iterative development and frequent inspection advantageous. Paint Pro operates in a competitive market where features may have to change frequently; Scrum allows the Prioritized Product Backlog to evolve as market information changes. Money Manager combines expanding functional needs with changing security requirements, creating precisely the kind of dynamic environment in which short Sprints, backlog reprioritization, and stakeholder feedback help reduce risk.

SCRUMstudy explicitly states that Scrum can be applied to products, services, and projects across industries and across varying levels of size and complexity. It is not restricted to simple software projects or projects with completely known requirements.

Thus each project can benefit from iterative delivery, continuous feedback, adaptation, and value-based prioritization. Because A, B, and C are all suitable, the correct response is D.

Study Guide reference: Introduction to Scrum - > Applicability of Scrum; Principles - > Iterative Development and Empirical Process Control.

========

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.

========

Among the options given, the Retrospect Project Meeting is the correct answer. SBOK describes this meeting as being conducted after the project to determine ways in which team collaboration and effectiveness can be improved in future projects. Participants examine successes, failures, inefficiencies, and potential improvement opportunities and document lessons learned.

At Sprint level, the equivalent continuous-improvement event is the Retrospect Sprint Meeting, where the team determines what to continue, start, or stop doing in future Sprints. However, that choice is not present in this question.

Sprint Planning is concerned with selecting and planning upcoming Sprint work. Sprint Review/Demonstrate and Validate Sprint focuses on inspecting deliverables and obtaining Product Owner/stakeholder feedback. “Review Project Meeting” is not the defined SBOK retrospective event represented here.

Because this question asks specifically about improving collaboration and effectiveness in the future, and because Retrospect Sprint is absent from the options, Retrospect Project is the correct meeting.

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

========

Statement C is false because risks differ substantially in both probability and impact. Risk assessment exists precisely to distinguish more significant risks from less significant ones.

SCRUMstudy defines risk as an uncertain event or set of events capable of affecting project objectives positively or negatively. Positive risks are called opportunities, while negative risks are threats.

Risk management is iterative and begins during project initiation, continuing throughout the project lifecycle. Risks are assessed primarily on their probability of occurrence and potential impact. Risks with high probability and high impact should generally receive greater attention than low-probability, low-impact risks.

This prioritization enables limited resources to be allocated rationally. Techniques such as Probability Impact Grids, Probability Trees, Expected Monetary Value, and Pareto Analysis help teams assess and compare exposures.

Therefore, the claim that all risks possess equal probability and impact directly contradicts the central mechanism of SBOK risk assessment and prioritization.

Study Guide reference: Risk - > Definition of Risk; Risk Assessment and Risk Prioritization.

========

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.

========

The Scrum Master is fundamentally a facilitator and supporting/servant leader rather than a traditional command-and-control project manager. Within the quality aspect, the Scrum Master's responsibilities include eliminating environmental obstructions that can negatively affect either the quality of deliverables or the effectiveness of Scrum processes.

Environmental obstructions may include organizational interference, inadequate tools, coordination problems, communication barriers, disruptive working conditions, or dependencies that prevent the Scrum Team from working effectively. The Scrum Master facilitates their removal so the self-organizing Scrum Team can concentrate on producing high-quality deliverables.

“Leader” is too broad for the specific role described in this question. Although servant leadership is a characteristic of a Scrum Master, the operational action of clearing impediments and creating a conducive environment is fundamentally facilitative. “Pacifier” and “Escalator” are not formal Scrum roles.

The distinction matters because the Scrum Master does not solve the technical work for the team or direct members on how to build deliverables. Instead, the role improves the environment and process in which the team operates.

Study Guide reference: Quality - > Summary of Responsibilities Relevant to Quality; Organization - > Scrum Master as Facilitator/Supporting Leader.

========

The Scrum Master should be selected based on characteristics such as problem-solving ability, availability, commitment, facilitation capability, and a supporting/servant leadership style. SCRUMstudy specifically identifies availability for meetings, skills for removing impediments, and commitment to maintaining a conducive work environment as relevant selection criteria.

Option D violates Scrum's principle of self-organization. The Scrum Master does not make technical implementation decisions on behalf of the Scrum Team. The Scrum Team has the authority and responsibility to determine how Prioritized Product Backlog Items are converted into finished deliverables. The Scrum Master's function is to facilitate, coach, protect the process, and remove obstacles—not to act as a technical project manager.

This distinction is fundamental. If the Scrum Master dictated technical decisions, responsibility would shift away from the self-organizing, cross-functional team and recreate a command-and-control structure inconsistent with Scrum.

Therefore, technical decision-making authority on behalf of the Scrum Team is not an appropriate Scrum Master selection criterion.

Study Guide reference: Organization - > Identify Scrum Master and Business Stakeholder(s) - > Selection Criteria; Scrum Team - > Self-organization and technical authority.

========

Option A does not correctly represent Scrum collaboration because it assigns business prioritization authority to the Scrum Team. Determining which User Stories are most important is principally the Product Owner's responsibility through management of the Prioritized Product Backlog. The Scrum Team subsequently estimates, commits to, and determines how to implement the selected work.

Options B, C, and D are genuine examples of collaborative behavior. Discussing the best implementation approach represents joint problem solving by a self-organizing team. Helping another team member overcome task difficulty demonstrates collective ownership rather than rigid individual specialization. Interacting with the Product Owner for requirement clarification enables the Scrum Team to understand intended value and Acceptance Criteria.

SBOK defines collaboration around awareness, articulation, and appropriation, treating delivery as shared value creation among team members and stakeholders.

The Scrum Team participates heavily in planning and can influence what it can realistically commit to, but it does not take over Product Owner accountability for ranking User Stories according to business value.

Study Guide reference: Principles - > Collaboration; Organization - > Product Owner versus Scrum Team Responsibilities.

========

After development is completed, the increment must be validated and demonstrated. The Scrum Team is responsible for ensuring that Sprint Deliverables satisfy the agreed quality conditions before presenting them in the Sprint Review/Demonstrate and Validate Sprint process. During that review, the team demonstrates completed functionality to the Product Owner and relevant business stakeholders, including customers or users where appropriate.

Acceptance Criteria provide the objective basis for checking whether a User Story satisfies the required functionality. Formal acceptance or rejection authority belongs to the Product Owner, not the Scrum Master.

Consequently, statement II is incorrect: the Scrum Master does not independently deploy the functionality into production merely because Sprint development has finished. Release is a business decision and follows the appropriate Ship Deliverables process. Statement IV is also incorrect because the Scrum Master cannot reject a User Story based on stakeholder feedback.

Statements I and III correctly represent demonstration and validation activities associated with completed Sprint work. Therefore, A is the intended answer.

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

========

The intended SMC answer is C — Ensure back-up resources are available. During the Form Scrum Team process, the Scrum Master facilitates selection and formation of the team, supports the Collaboration Plan and Team Building Plan, and ensures that appropriate backup resources are available where necessary. SCRUMstudy's current role-responsibility mapping explicitly assigns this responsibility to the Scrum Master.

Option A is primarily associated with the Product Owner, who defines the Project Vision and is accountable for aligning the project with business objectives. Option D is also a Product Owner responsibility: the Product Owner defines User Story Acceptance Criteria based on customer and business requirements, although the Scrum Master facilitates their creation and protects them from inappropriate modification during a Sprint.

There is nuance around option B: modern SBOK responsibility tables state that the Scrum Master helps identify business stakeholders. However, this legacy exam item is specifically testing the Form Scrum Team responsibility and its established keyed answer is C. The distinction is that identifying and formally representing business stakeholder interests remains primarily aligned with Product Owner/project initiation activities, whereas ensuring backup resources is explicitly stated as a Scrum Master duty.

Study Guide reference: Organization - > Scrum Master Responsibilities; Initiate - > Form Scrum Team.

========

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.

========

SBOK emphasizes behavioral characteristics that enable a self-organizing and cross-functional team rather than requiring every individual to possess narrow specialist mastery or extensive Scrum theory. SCRUMstudy identifies desirable Scrum Team members as independent, self-motivated, customer-focused, responsible, and collaborative.

A Scrum Team member must be capable of working collectively toward shared Sprint objectives while taking personal ownership of assigned or selected work. “Independent” in this context does not mean isolated; it means being capable of taking responsibility without requiring command-and-control supervision. Collaboration remains essential because knowledge, work, risk, and accountability are shared across the team.

Options A, B, and C contain useful competencies, but they are not the defining combination sought by the question. A Scrum Team may contain generalist-specialists with differing domain and technical abilities, and not every member needs mastery of Scrum-specific tools or sophisticated negotiation capabilities.

The combination of collaborative, highly motivated, and independent most closely reflects the qualities needed for successful self-organization and collective ownership.

Study Guide reference: Organization - > Scrum Team - > Team Characteristics; Principles - > Self-organization and Collaboration.

========

The intended process relationship is represented by option D. In the terminology used by this question set, Groom Prioritized Product Backlog continuously maintains and updates the backlog. A formal Prioritized Product Backlog Review Meeting is one of the principal mechanisms used to review requirements, obtain feedback, clarify User Stories, and incorporate appropriate changes. The resulting backlog is therefore updated and reprioritized.

Current SCRUMstudy materials use the term Refine Prioritized Product Backlog rather than “Groom,” but the underlying concept remains essentially the same: the Product Owner leads backlog maintenance with input from the Scrum Master, Scrum Team, and relevant business stakeholders.

Accepted Deliverables belong to Demonstrate and Validate Sprint, while the Sprint Backlog is created in planning rather than as the output of backlog refinement. Likewise, a Retrospect Sprint Meeting focuses on lessons learned and actionable improvements.

Thus, the valid Input/Tool/Output combination among the choices is D.

Study Guide reference: Implement - > Groom/Refine Prioritized Product Backlog - > Prioritized Product Backlog Review Meeting - > Updated Prioritized Product Backlog.

========

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.

========

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.

========

Story points are a relative estimation unit, not a direct representation of elapsed hours. They allow the Scrum Team to compare the overall size of User Stories by considering characteristics such as effort, complexity, uncertainty, and risk.

SCRUMstudy states that Relative Sizing/Story Points assigns a point value according to the overall size of a User Story, considering factors including the effort required and level of complexity. Once one item has been estimated, other User Stories can be estimated relative to that reference item.

Option A incorrectly equates story points with hours. Scrum can use time-based task estimates, but story points intentionally support relative rather than absolute estimation. Option C describes a count of completed stories rather than story points. Option D incorrectly assigns estimation responsibility to the Product Owner. Estimation is performed by the Scrum Team, because those performing the work are best positioned to judge its technical complexity and effort.

Story points consequently support velocity measurement and future forecasting without pretending that complex knowledge work can always be predicted precisely in hours.

Study Guide reference: Plan and Estimate - > Estimate User Stories - > Relative Sizing/Story Points.

========

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 described condition is fundamentally Poor Team Collaboration. Large Scrum projects depend on effective interaction among multiple Scrum Teams, particularly where deliverables, dependencies, shared components, or resources cross team boundaries. If teams begin working in isolation, communication decreases and coordination problems can develop even when each individual team appears internally productive.

The Scrum of Scrums mechanism exists specifically to improve coordination among multiple Scrum Teams by sharing progress, dependencies, impediments, and work that could affect other teams. Failure to communicate across those boundaries undermines one of Scrum's core principles—Collaboration.

Technical debt refers to accumulated future cost or rework caused by expedient technical decisions, incomplete engineering practices, or deferred quality work; that is not what the scenario describes. A risk is an uncertain event, whereas the lack of communication is already occurring. It could produce issues or risks, but its immediate organizational diagnosis is poor collaboration.

Thus, the Chief Scrum Master should identify this as a team collaboration problem and facilitate mechanisms that restore transparency, coordination, and cross-team communication.

Study Guide reference: Organization - > Scrum in Large Projects; Principles - > Collaboration; Scrum of Scrums.

========

Option A most accurately reflects the Product Owner's authority during backlog refinement and change management. The Product Owner decides which stakeholder input is relevant, evaluates suggested changes, and determines which changes should progress as formal Change Requests or be incorporated into the Prioritized Product Backlog.

Option B is incorrectly worded. The Scrum Master protects committed Sprint requirements and Acceptance Criteria throughout the active Sprint, not merely during the Sprint Review Meeting. The distinction matters because the Sprint Review occurs at the end of the Sprint and is specifically intended to validate completed deliverables and obtain feedback.

Option C describes development work that belongs to the Scrum Team. Stakeholders provide requirements, feedback, and Change Requests; they do not directly incorporate features into Sprint Deliverables.

Option D improperly gives the Scrum Team unilateral business authority over an urgent requirement change. Significant business changes are evaluated through the Product Owner/change-management mechanism. If a change is critical enough to invalidate current Sprint work, the Sprint can be terminated and replanned through the applicable Scrum governance process.

Therefore, A is the correctly matched responsibility.

Study Guide reference: Change - > Integrating Change; Product Owner Responsibilities; Groom/Refine Prioritized Product Backlog.

========

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.

========

A Scrumboard represents work associated with a particular Sprint. During that Sprint, tasks move through workflow states such as To Do, In Progress, Testing, and Done. The board is updated continuously so that the team has a transparent view of current progress.

At the completion of the Sprint, however, that Sprint's working board is no longer the active execution board. Earlier SBOK guidance explicitly describes the Scrumboard as being reset or wiped off, with a new Scrumboard created for the next Sprint. Current SBOK guidance similarly states that one Scrumboard is valid for one Sprint and that the Scrum Team creates a new board for the next Sprint.

This distinction is important because velocity is not calculated merely by retaining two physical boards side by side. Historical metrics and Sprint results can be preserved through appropriate tracking mechanisms, while the operational Scrumboard remains focused on current Sprint work.

Thus the exam wording “reset or wiped off” reflects the SBOK concept that each Sprint receives its own current execution view rather than indefinitely accumulating tasks from earlier Sprints.

Study Guide reference: Implement - > Create Deliverables - > Updated Scrumboard; Scrumboard lifecycle across Sprints.

========

Scrum balances flexibility with Sprint-level stability. Once the team commits to Sprint work, outside interference and arbitrary requirement changes should be prevented so that the Scrum Team can maintain focus and produce the committed increment.

The Scrum Master helps protect the Scrum Team from disruption, while the Scrum Team maintains commitment to the Sprint work. New Change Requests generally enter the Prioritized Product Backlog and are evaluated and prioritized for a future Sprint rather than being inserted indiscriminately into the active Sprint.

Option B violates this stability principle by suggesting that a Sponsor should introduce and approve changes directly during the Sprint. Option C is incorrect because Scrum does not seek “complete stability” across the project; the overall project remains deliberately adaptive. Option D is too absolute. Change approval authority can vary according to organizational tolerances and program/portfolio governance, even though the Product Owner controls project backlog prioritization.

Scrum's objective is therefore stable execution inside the Sprint and flexibility between Sprints, not resistance to change throughout the project.

Study Guide reference: Change - > Balancing Flexibility and Stability; Maintaining Sprint Stability.

========

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.

========