Free SMC Practice Test Questions and Answers (2026)

The effectiveness of a Scrum Team is heavily dependent on the traits of its members. The ideal team is a cohesive unit capable of delivering a potentially shippable increment each Sprint. This requires a combination of skills and attitudes. A collaborative nature is fundamental for working together effectively. A cross-functional outlook is crucial because Scrum Teams are designed to have all the competencies needed to accomplish the work without depending on others not part of the team; individual members with broad skills (T-shaped) enhance this capability. Finally, Business Domain knowledge allows the team to understand the user stories, make informed decisions, and deliver true value to the customer.

A. Not every team member is expected to be a "Scrum Expert"; that is the primary role of the Scrum Master.

B. "Self-organizing" is a characteristic of the team as a whole, not necessarily an individual trait, and "Negotiation skills" are less critical than core traits like cross-functionality.

D. The term "Independent" is contrary to the Scrum value of collaboration. Team members are highly interdependent and must work closely together to achieve Sprint Goals.

1. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition.

Section 4.2.2.2

Scrum Team Selection Criteria: This section explicitly lists key criteria for selecting team members. It states

"Key criteria to be considered during team selection are: cross-functional skills so the team has all the required expertise to deliver value; collaboration and co-location...; self-organization; and motivation." This directly supports "Collaborative" and "Cross-functional outlook." Business domain knowledge is an essential part of the expertise required to deliver value.

2. Moe

N. B.

Dingsøyr

T.

& Dybå

T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology

52(5)

480-491.

Page 486

Section 4.2.1

Shared mental models: The study highlights the importance of "shared understanding of the task and the business domain" for team effectiveness

supporting the need for Business Domain knowledge. It also emphasizes coordination and mutual support

which are facets of a collaborative environment. The concept of cross-functionality is discussed as enabling the team to handle diverse tasks internally.

DOI: https://doi.org/10.1016/j.infsof.2009.11.004

3. Hoda

R.

Noble

J.

& Marshall

S. (2011). The impact of agile methods on software project management. 2011 International Conference on Software and System Process (ICSSP).

Page 91

Section IV-B

The Team: This paper discusses the characteristics of agile teams

noting that "Agile teams are typically cross-functional... and collaborative." This reinforces that collaboration and a cross-functional nature are defining traits of successful Scrum teams.

DOI: https://doi.org/10.1145/1961259.1961276

According to ScrumStudy’s SBOK® Guide, the Daily Standup Meeting is the designated forum for the Scrum Team to report daily progress and any impediments. A key question addressed in this meeting is, "What impediments or obstacles, if any, are you facing?" The Scrum Master is explicitly responsible for updating the Impediment Log with any issues raised. This meeting occurs daily throughout the Sprint, concurrent with the Create Deliverables process, making it the primary and most consistent time for formally logging impediments that affect the team's work.

Sprint Review Meetings: The focus is on demonstrating the working product increment to stakeholders and gathering feedback, not primarily on logging internal team impediments.

Release Planning Meetings: This is a high-level planning activity focused on the release schedule and scope; it is not used for managing the detailed, sprint-level Impediment Log.

Sprint Planning Meetings: While potential roadblocks may be identified during planning, the SBOK® Guide explicitly designates the Daily Standup as the process with the updated Impediment Log as a formal output.

1. SCRUMstudy

"A Guide to the Scrum Body of Knowledge (SBOK® Guide)

" 3rd Edition

2017.

Section 10.4.3

Outputs from Conduct Daily Standup: This section explicitly lists "Impediment Log (updated)" as a primary output of the Daily Standup process. It states

"The Scrum Master updates the Impediment Log with any impediments that are raised by the Scrum Team during the Daily Standup." (Page 218).

Section 7.3.2

Impediment Log: This section describes the tool and notes

"Impediments are discussed in the Daily Standup Meetings and also may be discussed in the Sprint Retrospective Meetings." (Page 128).

Chapters 8

9

and 10: The descriptions of Sprint Planning

Sprint Review

and Release Planning meetings do not list the Impediment Log as a formal output

reinforcing that the Daily Standup is the correct context for this activity as per the framework.

This question assesses the understanding of key roles and their responsibilities concerning business justification as defined in the Scrum framework, particularly by ScrumStudy. The Product Owner is explicitly responsible for maximizing business value and maintaining the project's business justification (II-b). The Scrum Master serves as a facilitator, guiding the team and Product Owner in Scrum processes, which includes creating and assessing business justification (I-d). The Sponsor is the entity providing the financial resources for the project (III-c). The Scrum Team contributes its technical and domain expertise to help the Product Owner develop a viable and well-grounded business case (IV-a).

A: Incorrectly assigns the Scrum Master the Product Owner's core responsibility for business value and misattributes the Scrum Master's guidance role to the Scrum Team.

B: Incorrectly assigns the Scrum Team's role of providing expertise to the Scrum Master and the Product Owner's value responsibility to the Sponsor.

C: Incorrectly assigns the Sponsor's funding role to the Scrum Master and the Scrum Master's facilitation role to the Product Owner.

1. Product Owner Role (II-b): "The Product Owner is the person responsible for maximizing business value for the project. He or she is responsible for articulating customer requirements and maintaining business justification for the project."

Source: A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition

SCRUMstudy

2017

Section 3.5.1

Page 48.

2. Scrum Master Role (I-d): "The Scrum Master is a facilitator who ensures that the Scrum Team is provided with an environment conducive to completing the project successfully. The Scrum Master guides

facilitates

and teaches Scrum practices to everyone involved in the project..."

Source: A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition

SCRUMstudy

2017

Section 3.6.1

Page 51.

3. Sponsor Role (III-c): "The sponsor is the individual or the organization that provides resources and support for the project... The sponsor is the person or entity funding the project."

Source: A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition

SCRUMstudy

2017

Section 2.3

Page 22.

4. Scrum Team Role (IV-a): "The Scrum Team

also referred to as the Development Team

is a group of individuals who work on the User Stories in the Sprint Backlog... The Scrum Team provides inputs to the Product Owner for creation of the Prioritized Product Backlog." This includes providing expertise for estimation and feasibility

which are crucial for business justification.

Source: A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition

SCRUMstudy

2017

Section 3.7.1

Page 54.

The Internal Rate of Return (IRR) is a standard financial metric used in capital budgeting to estimate the profitability and value of potential investments or projects. It represents the discount rate at which the Net Present Value (NPV) of all future cash flows equals zero. In the context of project justification, IRR is used to rank and select projects. A project is typically accepted if its IRR exceeds the organization's required rate of return or hurdle rate. This method directly helps in quantifying and estimating the financial value a project is expected to deliver, which is a key aspect of value-based prioritization in frameworks like Scrum.

B. Net Rate of Return: This is not a standard, formally defined financial metric used for project valuation in the same way as IRR or NPV.

C. Present Rate of Return: This is not a recognized financial term and is likely a distractor confusing concepts like "Present Value" and "Rate of Return."

D. Estimated Rate of Return: This is a generic descriptive term, not a specific calculation method. IRR is one specific type of estimated rate of return.

---

1. SCRUMstudy. (2021). A Guide to the Scrum Body of Knowledge (SBOK® Guide) (4th ed.). Section 8.2.2.2

Project Justification. The guide explicitly lists "Internal Rate of Return (IRR)" as a method used to justify projects.

2. Brealey

R. A.

Myers

S. C.

& Allen

F. (2017). Principles of Corporate Finance (12th ed.). McGraw-Hill Education. Chapter 5

"Net Present Value and Other Investment Criteria

" provides a detailed explanation of IRR as a fundamental method for evaluating project value.

3. MIT OpenCourseWare. (2008). 15.401 Finance Theory I

Lecture Notes

Investment Decision Rules. Massachusetts Institute of Technology. The courseware details the application and calculation of IRR as a primary rule for making investment and project decisions. (Available at: ocw.mit.edu)

4. Ghasemzadeh

F.

& Archer

N. P. (2000). Project portfolio selection through decision support. Decision Support Systems

29(1)

73-88. This academic paper discusses various financial models for project selection

identifying IRR as a key quantitative method for assessing project value. (https://doi.org/10.1016/S0167-9236(00)00065-8)

According to the Scrum Body of Knowledge (SBOK™ Guide), benefits are realized when demonstrable value is delivered to and accepted by the customer. This cycle begins in the Demonstrate and Validate Sprint process, where stakeholders review and accept the Sprint’s potentially shippable increment. The value is fully realized during the Ship Deliverables process when the accepted product increment is released to users. The Retrospect Sprint and Retrospect Project processes are crucial for assessing whether the intended value was delivered and for improving future benefits realization, thus confirming the project's success and capturing lessons learned.

A. "Conduct Release Planning" and "Create Deliverables" are processes for planning and building value, not for realizing the benefits of delivered functionality.

C. "Demonstrate and Validate Project" is not a standard SBOK™ process name, and "Grooming Product Backlog" is a preparatory activity for future Sprints.

D. This option uses incorrect process names like "Demonstrate and Validate Project" and "Verify Deliverables," which are not part of the official SBOK™ framework.

---

1. SCRUMstudy

A Guide to the Scrum Body of Knowledge (SBOK™ Guide)

3rd Edition.

Chapter 11: Review and Retrospect. This chapter details the "Demonstrate and Validate Sprint" process (Section 11.1)

where the Sprint output is presented to stakeholders for approval

a key step in validating value. It also covers the "Retrospect Sprint" process (Section 11.2)

which assesses the value delivered.

Chapter 12: Release. This chapter describes the "Ship Deliverables" process (Section 12.1)

which is the point of actual delivery and benefits realization for the customer. It also details the "Retrospect Project" process (Section 12.2)

which includes confirming the achievement of project objectives and benefits.

Section 2.4: Value-based Prioritization. This principle underpins the entire framework

emphasizing that the primary goal of Scrum is to deliver maximum business value

which is realized through the processes listed in the correct answer.

The Scrum of Scrums (SoS) meeting is a key mechanism for coordinating multiple Scrum Teams. Its primary objective is to focus on integration and coordination by discussing progress, impediments, and dependencies.

Option (A) is correct because a central role of the Scrum Master is to remove impediments. The SoS provides a forum to identify, escalate, and coordinate the resolution of impediments that affect multiple teams.

Option (C) is also correct as the SoS is the primary venue for managing inter-team dependencies. Discussing actions that might affect other teams is crucial for ensuring smooth integration and preventing one team from blocking another. The Scrum Body of Knowledge (SBOK™ Guide) explicitly lists this as a key question to be addressed.

B. Discuss what each individual development team member has worked on since the last time all Scrum Masters met.

This level of detail is too granular. The Scrum of Scrums focuses on team-level coordination, not the tasks of individual members, which are discussed in the team's Daily Standup.

D. Share a status update on all individual team member' tasks.

This is incorrect for the same reason as option B. The SoS is a coordination and problem-solving meeting, not a detailed status report on individual tasks.

1. A Guide to the Scrum Body of Knowledge (SBOK™ Guide)

3rd Edition.

Page 188

Section 7.4

Scrum of Scrums Meeting: This section states

"This meeting is the forum for the representatives of the various Scrum Teams to discuss their respective progress

impediments

and dependencies." This directly supports both options A (impediments) and C (dependencies).

Page 188

Section 7.4

Scrum of Scrums Meeting: The guide lists four key questions for the SoS meeting. The fourth question is

"What is our team planning to do that might affect other teams?" This provides direct and explicit support for option C. The discussion of impediments supports option A.

Adaptation, one of the three pillars of Scrum, involves adjusting a process or product in response to an inspection to minimize deviation from goals. Seeking help (A), mentoring (B), and applying lessons learned (C) are all adaptive actions taken to improve performance or processes based on a recognized need. In contrast, using information radiators like Scrum boards or burndown charts is a primary example of Transparency. These tools make progress, work, and impediments visible to everyone. While this transparency is a prerequisite for inspection and subsequent adaptation, the act of using the radiator itself is about making information available, not the adjustment based on that information.

A. Seeking help from team members: This is a direct adaptation to an identified impediment or knowledge gap to keep work flowing.

B. Experienced team members mentoring new members: This is the team adapting its internal processes to address a skills gap and improve overall capability.

C. Recording Lessons learned to improve processes and address problems: This is a formal adaptation mechanism, typically from a retrospective, to adjust future actions based on past results.

1. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition.

Section 2.3.3

Adaptation: "Adaptation refers to adjusting a process or the product being built. In Scrum

adaptation happens when the Scrum Core Team or the Stakeholder(s) learn something new through transparency and inspection." This supports why A

B

and C are adaptations.

Section 2.3.1

Transparency: "Transparency allows all facets of any Scrum process to be observed by everyone. This sharing of information... leads to a high level of trust... An example of this is the use of a Scrumboard to show the progress of the team." This directly links information radiators (like a Scrumboard) to the principle of Transparency

not Adaptation.

2. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

4th Edition.

Section 2.3

Scrum Principles - Empirical Process Control: This section reiterates the three pillars. It states

"Transparency in Scrum is making all information related to the project visible and accessible to all stakeholders... Inspection in Scrum refers to the monitoring of the project’s progress... Adaptation in Scrum refers to the adjustment of the process and the product based on the results of the inspection." The use of an information radiator is an act of making information visible (Transparency)

which then enables Inspection and Adaptation.

Quality Assurance (QA) is a process-oriented activity focused on ensuring that the processes, standards, and procedures used to manage and create the deliverables are appropriate for the project and are being correctly implemented. It involves auditing and evaluating the quality management system itself to ensure it remains effective and relevant. The primary goal of QA is to prevent defects by improving the development and testing processes, rather than finding defects in the final product, which is the focus of Quality Control.

B. This describes Quality Planning, which involves defining quality standards, acceptance criteria, and key responsibilities before the work begins.

C. This describes Quality Control, which involves the execution of planned activities (like testing) to inspect the actual deliverables and ensure they meet the defined quality standards.

D. This describes the principle of empirical process control and continuous backlog refinement, which are core to the Scrum framework but do not define Quality Assurance.

1. SCRUMstudy. (2021). A Guide to the Scrum Body of Knowledge (SBOK® Guide) (4th ed.). VMEdu

Inc.

Section 7.3

Quality Assurance: "Quality Assurance is the evaluation of processes and standards that govern quality management in a project to ensure that they continue to be relevant. It is a proactive quality process that aims to prevent defects in the deliverables." (This definition directly corresponds to option A).

Section 7.2

Quality Planning: The guide describes this process as involving the definition of Acceptance Criteria and quality standards

which aligns with the description in option B.

Section 7.4

Quality Control: The guide defines this as "the execution of the planned quality activities by the Scrum Team in the process of creating deliverables that are potentially shippable

" which directly corresponds to option C.

The Storming stage is characterized by conflict and disagreement as team members assert their individuality and challenge established norms. The Scrum Master's role is most critical and active during this phase. They must act as a coach and mediator, facilitating difficult conversations and resolving conflicts to guide the team toward collaboration and mutual respect. This intensive, hands-on intervention is essential to prevent the team from becoming dysfunctional and is more demanding than the directive guidance in the Forming stage or the facilitative support required in the Norming and Performing stages, where the team becomes progressively more self-organizing.

A. Forming: The Scrum Master is directive, but team conflict is low, requiring less intensive interpersonal intervention compared to the Storming stage.

C. Norming: The team begins to resolve conflicts and self-organize, so the Scrum Master’s active involvement decreases, shifting towards facilitation rather than direct mediation.

D. Performing: The team is highly autonomous and self-managing. The Scrum Master’s role is focused on removing external impediments, requiring minimal internal team intervention.

---

1. SCRUMstudy™

A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition (2017).

Section 6.2.3.2

Team Building Activities: The guide discusses Tuckman's stages of group development. It describes the Storming stage as a period of conflict where the Scrum Master must coach the team in problem-solving and conflict resolution. This implies a highly active and crucial role to navigate this phase successfully

more so than in other stages where the team is either just beginning (Forming) or becoming self-sufficient (Norming/Performing).

2. Moe

N. B.

Dingsøyr

T.

& Dybå

T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology

52(5)

480-491.

Section 4.2

Team Development: This study analyzes agile team dynamics. It notes that in the initial phases

corresponding to Forming and Storming

teams face significant challenges in establishing norms and handling disagreements. The study highlights the need for facilitation and coaching to overcome these "stormy" periods before a team can become effective and autonomous

supporting the premise that the facilitator/Scrum Master role is most active during this conflict-ridden stage.

DOI: https://doi.org/10.1016/j.infsof.2009.11.004

3. Tuckman

B. W.

& Jensen

M. A. C. (1977). Stages of small-group development revisited. Group & Organization Studies

2(4)

419-427.

Page 421-422

Stage 2: Storming: The original and updated work describes this stage as being characterized by "conflict and polarization around interpersonal issues." A leader's role (analogous to a Scrum Master) is to help the group navigate this conflict to avoid getting stuck

which necessitates a more active and engaged approach than in any other stage.

The Product Owner's primary responsibility is maximizing the value of the product by managing and prioritizing the Product Backlog. While risk is a critical factor in this prioritization, the formal responsibility for creating and communicating a separate, prioritized list of risks to the Scrum Team is not solely the Product Owner's. Risk management in Scrum is a collaborative effort involving the entire Scrum Team and relevant stakeholders, facilitated by the Scrum Master. The Product Owner incorporates risk assessment into the prioritization of Product Backlog Items, rather than managing a separate risk-only list.

A. Continuous communication with stakeholders about risks is a fundamental aspect of transparency and is crucial for managing expectations and making informed decisions.

B. The Daily Standup is an appropriate forum for the Scrum Team to raise any impediments, including newly identified risks related to their tasks.

D. The Risk Burndown Chart is a recognized optional tool within the ScrumStudy framework used to track and communicate the project's overall risk exposure over time.

1. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition.

Supporting Correct Answer (C): Section 3.5.1

"Product Owner

" details the role's responsibilities

focusing on being the "voice of the customer" and managing the Product Backlog. It does not assign the task of creating and communicating a prioritized risk list. The risk management process described in Chapter 7

"Risk

" emphasizes a collaborative approach

stating

"The Product Owner works with the Scrum Team and Stakeholder(s) to identify

assess

and respond to risks" (Section 7.4)

which contradicts the unilateral responsibility implied in option C.

Supporting Incorrect Option (A): Section 7.4.4

"Risk Communication

" explicitly states

"The Stakeholders should be kept informed about risks

including the potential impact of the risks and the plans for responding to each risk."

Supporting Incorrect Option (B): Section 6.4

"Daily Standup Meeting

" notes that the meeting is used to communicate impediments. A risk impacting a task is a valid impediment to be discussed.

Supporting Incorrect Option (D): Section 7.4.4

"Risk Communication

" introduces the Risk Burndown Chart as a tool for communicating information related to risks. Figure 7-11 provides an example of this chart.

Scrum embraces change through continuous refinement and reprioritization of the Product Backlog, managed by the Product Owner. While collaboration with the customer is key, Scrum does not use a formal process for managing "large numbers of Change Requests" typical of traditional project management. Instead, changes are incorporated as new or modified items in the backlog for consideration in future Sprints. Options B, C, and D describe core, direct benefits of collaboration in Scrum: collective risk management, shared responsibility for achieving Sprint Goals, and continuous process improvement through events like the Sprint Retrospective.

B. Collaboration is essential for risk management in Scrum. The team collectively identifies, assesses, and decides on responses to risks throughout the project lifecycle.

C. The principle of collective ownership, fostered by collaboration, means team members assist each other to ensure the Sprint Goal is met, even if individual tasks face delays.

D. The Sprint Retrospective is a dedicated, collaborative event where the Scrum Master facilitates the team's discussion on process improvements for subsequent Sprints, embodying continuous improvement.

1. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition.

For Correct Answer (A): Section 8.3.1

"Managing Changes in a Scrum Project

" explains that changes are handled by the Product Owner who maintains the Prioritized Product Backlog. The guide contrasts this flexible approach with the formal change control procedures of traditional project management

which deal with "Change Requests."

For Incorrect Option (B): Chapter 7

"Risk

" particularly Section 7.1

describes risk management as an iterative and collaborative process involving the entire Scrum Team to identify

assess

and respond to risks.

For Incorrect Option (C): Section 3.7

"Collaboration

" emphasizes that the Scrum Core Team works together to create deliverables. This principle underpins the team's ability to self-organize and align to meet Sprint commitments.

For Incorrect Option (D): Section 11.4

"Retrospect Sprint

" details the collaborative meeting where the team discusses what went well and what did not

creating actionable improvements for the next Sprint

which is a cornerstone of continuous improvement.

The primary objective of the Retrospect Sprint Meeting is to inspect the previous Sprint with regard to the processes, tools, people, and relationships within the Scrum Team. The team collaboratively discusses what went well, what could be improved, and creates a plan for implementing process improvements in the next Sprint. This meeting is focused on improving the team's effectiveness and quality of work (how the team works). Identifying new product features (what the team builds) is outside the scope of this meeting; that function is managed in the Product Backlog and addressed during events like Product Backlog Refinement and Sprint Planning.

A. Identifying process improvements is a core objective of the Sprint Retrospective, as the team seeks to adapt and enhance its way of working.

B. Identifying best practices is part of reflecting on what went well, ensuring that successful techniques are continued in future Sprints.

D. Identifying process problems and bottlenecks is a fundamental purpose of this meeting, allowing the team to address impediments and improve workflow.

1. SCRUMstudy

A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition.

Page 295

Section 12.3: The guide states

"The purpose of the Retrospect Sprint Meeting is for the Scrum Team to inspect the previous Sprint

identify what went well and what did not

and make improvements for future Sprints." It explicitly focuses on process

not product features. The outputs listed are "Agreed upon Actionable Improvements" and "Updated Scrum Guidance Body Recommendations

" which relate to process enhancement.

2. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide.

Page 10

"Sprint Retrospective": "The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals

interactions

processes

tools

and their Definition of Done." This definition clearly excludes the discussion of new product functionality.

3. Stray

V.

Sjøberg

D. I.

& Dybå

T. (2016). The daily stand-up meeting: A grounded theory study. Journal of Systems and Software

114

101-124.

DOI: https://doi.org/10.1016/j.jss.2016.01.004

While focused on the daily stand-up

this and similar academic studies on Scrum meetings consistently differentiate the purpose of each ceremony. The retrospective is universally defined in academic literature as a mechanism for process improvement and team reflection

distinct from product planning activities.

The Scrum of Scrums (SoS) Meeting is a core practice for scaling Scrum to large projects involving multiple teams. It serves as a crucial coordination mechanism where representatives (often the Scrum Masters or designated team members) from different Scrum Teams meet. The primary purpose is to discuss progress, address cross-team dependencies, and resolve impediments that impact more than one team. This ensures that all teams remain synchronized and integrated, facilitating the effective delivery of a cohesive product increment from the collective effort.

B. Daily Standup Meeting: This meeting is for coordination and synchronization within a single Scrum Team, not for coordinating activities between multiple teams.

C. Sprint Review Meeting: This meeting focuses on demonstrating the product increment to stakeholders and gathering feedback, not on operational coordination between development teams.

D. Sprint Planning Meeting: This meeting is conducted by an individual Scrum Team to plan the work for its own upcoming Sprint.

1. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition. ScrumStudy

VMEdu

Inc.

Section 8.4

"Scrum of Scrums (SoS) Meeting

" Page 198: "The Scrum of Scrums (SoS) Meeting is an important element when scaling Scrum to large projects. It is a meeting that is typically held on a daily basis to coordinate the work of multiple Scrum Teams... The objective of the SoS meeting is to focus on areas of coordination and integration between the different Scrum Teams."

2. Stray

V.

Sjøberg

D. I.

& Dybå

T. (2016). The daily stand-up meeting: A grounded theory study. Journal of Systems and Software

114

101-124.

Section 5.1

Page 115: This study analyzes the daily stand-up meeting

confirming its function as an internal team coordination mechanism. It contrasts this with coordination needs between teams

for which other mechanisms like the Scrum of Scrums are required. (DOI: https://doi.org/10.1016/j.jss.2016.01.004)

In the Scrum framework, the Development Team is explicitly required to be cross-functional. This means the team as a whole must possess all the necessary skills and competencies—such as design, development, quality assurance, and operations—to create a "Done," potentially releasable product Increment. This collective capability ensures the team can work autonomously without depending on external specialists to complete the work planned for a Sprint. The term "cross-functional" refers to the collective skill set of a team, not the attributes of an individual role.

B. Product Owner: This is an individual role responsible for managing the Product Backlog. The term "cross-functional" describes a team's collective skill composition, not a single person.

C. All of the above: This is incorrect because the Product Owner and Scrum Master are individual roles. The principle of being cross-functional is a defining characteristic of the Development Team.

D. Scrum Master: This is an individual role acting as a servant-leader and coach. Like the Product Owner, "cross-functional" is not a term used to describe this role.

1. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition.

Page 48

Section 3.4.1

Development Team: "The Development Team is a group of individuals who work on the User Stories in the Sprint Backlog to create a Deliverable. It is a cross-functional and self-organizing team that is responsible for the hands-on work of creating the Deliverable." This directly states that the Development Team is cross-functional.

2. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition.

Page 11

Section 1.4.4

Self-organization: "The Scrum Team is a cross-functional team containing all the skills to complete the project from start to finish." While this refers to the entire Scrum Team

the question breaks the team into its component roles. The Development Team is the component that embodies the collective skills for product creation

making it the most accurate answer among the choices.

3. University of Virginia

Darden School of Business.

Courseware on Digital Product Management

"Agile Development: Scrum." It is consistently taught that a core tenet of Scrum is the formation of a cross-functional Development Team. The course materials explain

"The Development Team is cross-functional

with all the skills as a team necessary to create a product Increment." This highlights that the characteristic is applied to the team responsible for development work.

The best solution aligns with the core Scrum principle of Self-organization. Scrum teams are empowered to manage their own work and processes to achieve the project's objectives. As a Scrum Master, your role is to be a facilitator and servant-leader who fosters an environment where the Development Team can form and organize itself. Allowing developers to self-organize promotes greater buy-in, motivation, and collective ownership of the work. This approach leverages the team's collective intelligence to create the most effective structure for delivering value, which is a fundamental tenet of the Scrum framework.

A. Recruit people from departments within the organization that can best support the project.

This describes a traditional, top-down management approach, which is contrary to the Scrum principle of empowering a self-organizing team.

B. Hire a Scrum Coach to help the developers become self-managing.

This is an action taken to improve an existing team's maturity and practices, not the primary method for the initial creation of the team.

D. Have the Development Team work directly with the customers of the project.

This is a valuable practice for a team that has already been formed (i.e., stakeholder collaboration), not a method for its initial formation.

---

1. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition. VMEdu

Inc. (2017).

Section 2.5

Self-organization

p. 22: "The Scrum framework promotes a self-organized working style where the team has a high degree of autonomy and flexibility in accomplishing the project objectives... The team itself decides how to best accomplish the work

rather than being directed by others outside the team." This reference directly supports the principle behind allowing the team to self-organize.

2. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition. VMEdu

Inc. (2017).

Section 6.2

Scrum Master

p. 96: "The Scrum Master is a facilitator who ensures that the Scrum Team is provided with an environment conducive to completing the project successfully. The Scrum Master guides

facilitates

and teaches Scrum practices to everyone involved in the project..." This defines the Scrum Master's role as a facilitator who would enable the team's self-organization rather than directing its formation.

The Scrum Master must ensure the Scrum Team creates deliverables as agreed upon because without completed deliverables that meet the Definition of Done and acceptance criteria, there would be nothing to ship. This is the fundamental prerequisite for the Ship Deliverables process. The Scrum Master facilitates the team's work to ensure deliverables are created according to commitments made during Sprint Planning, enabling the Product Owner to deploy them successfully.

B. Updating Release Plan and Backlog occurs during Release Planning, not as a prerequisite for Ship Deliverables.

C. Release Planning Schedule creation happens earlier in the project lifecycle, not during Ship Deliverables.

D. Acceptance/rejection occurs in Demonstrate and Validate Sprint, which precedes Ship Deliverables process.

- SBOK Guide (ScrumStudy

2017)

Chapter 13: Ship Deliverables

Section 13.1

pp. 251-252

- SBOK Guide (ScrumStudy

2017)

Chapter 8: Initiate

Section 8.7.3

p. 156

- SBOK Guide (ScrumStudy

2017)

Chapter 11: Create Deliverables

Section 11.1

pp. 217-218

The process of prioritizing the Product Backlog involves evaluating User Stories based on specific criteria to determine their order. Key factors for this evaluation include the business value they generate (A), their dependencies on other stories (B), and the associated risks or opportunities for innovation (C). A User Story that is very difficult to understand, estimate its value, or determine the effort required for its creation is not considered "Ready." According to the DEEP (Detailed appropriately, Estimated, Emergent, Prioritized) criteria for a healthy backlog, items must be estimable. Such an ill-defined story is excluded from the active prioritization process until it undergoes further refinement to gain clarity.

A. User Stories that generate value for the customer. This is incorrect because maximizing customer value is the primary goal of the Product Owner and a fundamental criterion for prioritization.

B. User Stories that are dependent on others for completion. This is incorrect because dependencies are a crucial factor in ordering the backlog to ensure a logical and efficient workflow.

C. User Stories that are innovative and may or may not be successfully created. This is incorrect because evaluating risk versus potential reward is a key responsibility of the Product Owner during prioritization.

1. VMEdu Inc. (2017). A Guide to the Scrum Body of Knowledge (SBOK® Guide) (3rd ed.).

Section 3.4

"Prioritization

" p. 61: This section explicitly states the factors used for prioritization: "The Product Owner prioritizes the User Stories based on a combination of business value

risk or uncertainty

and dependencies." This directly confirms that options A

B

and C describe stories that are evaluated.

Section 3.3

"Prioritized Product Backlog

" p. 59: This section introduces the DEEP criteria for a good backlog. It specifies that User Stories must be "Estimated." A story that is "very difficult to determine its value

create and/or deliver" (Option D) fails this criterion and is therefore not ready for prioritization.

2. Sutherland

J.

& Schwaber

K. (2020). The Scrum Guide. Scrum.org.

Product Backlog Section

p. 12: "Product Backlog items that can be done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities." This supports the reasoning that a story which is difficult to understand or create (as in option D) is not "ready" and thus would be excluded from prioritization for near-term Sprints until it is refined.

The activity described in option A is not a correct representation of collaboration in Scrum. According to the Scrum framework, the Product Owner is solely responsible for prioritizing the Product Backlog, which means they decide which User Stories are most important to deliver the maximum business value. The entire Scrum Team does not collectively decide on the importance of User Stories. During the Sprint Planning meeting, the Product Owner presents the prioritized items, and the Development Team then selects the amount of work they can commit to completing in the upcoming Sprint.

B. This is a core collaborative activity. The self-organizing Development Team collectively decides on the best technical approach to create the Sprint deliverables.

C. This exemplifies strong team collaboration and shared ownership, where team members support each other to achieve the Sprint Goal.

D. This is a fundamental collaborative process. Continuous communication between the Development Team and the Product Owner is essential for clarifying requirements and ensuring the right product is built.

1. ScrumStudy. (2017). A Guide to the Scrum Body of Knowledge (SBOK™ Guide) (3rd ed.).

Page 41

Section 3.3.2

Responsibilities of the Product Owner: "The Product Owner is the person responsible for maximizing business value for the project... The Product Owner is also responsible for managing the Product Backlog

including its content

availability

and prioritization." This confirms that prioritization is the Product Owner's responsibility

not the entire team's.

Page 169

Section 8.3.3.1

Sprint Planning Meeting: "During the first half of the meeting

the Product Owner explains the highest priority User Stories or requirements in the Prioritized Product Backlog to the Scrum Team." This outlines the correct process

contrasting with the scenario in option A.

2. Serrador

P.

& Pinto

J. K. (2015). Does Agile work? — A quantitative analysis of agile project success. International Journal of Project Management

33(5)

1040-1051.

Page 1043

Section 2.2

Agile Project Management: The paper discusses the distinct roles in Agile

noting that the Product Owner's role is to "prioritize features" and act as the voice of the customer

while the team focuses on delivery. This academic source supports the separation of duties described in the SBOK™ Guide. (DOI: https://doi.org/10.1016/j.ijproman.2015.01.006)

3. University of Virginia

Darden School of Business. (n.d.). Agile Development in Practice. Courseware.

In modules discussing Scrum roles

the curriculum emphasizes that the Product Owner is the "single point of accountability for the product backlog" and is responsible for "ordering the backlog items to best achieve the project's goals." This aligns with the principle that the team does not decide the priority of the stories.

Team velocity is a primary metric in Scrum used to measure the amount of work a team completes during a Sprint. It is calculated by summing the story points of all User Stories that are fully completed and meet the Definition of Done by the end of the Sprint. Velocity is not a measure of hours worked or time spent, but rather a representation of the volume of value delivered. Its primary purpose is to assist the team with forecasting and planning for future Sprints, providing an empirical basis for estimating how much work can be taken on in the next iteration.

A. Team velocity is the total number of hours the team has worked during a Sprint.

This is incorrect. Velocity measures the output of completed work (story points), not the input of effort (hours).

C. Team velocity is the percentage of story points that have been Done versus those committed.

This is incorrect. This describes commitment reliability or a "say/do" ratio, which is a different performance metric than velocity.

D. Team velocity is the actual time spent on delivering User Stories.

This is incorrect. Velocity is an abstract measure of the size and complexity of work items, not the actual time recorded to complete them.

---

1. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition. VMEdu

Inc. (2017).

Section 8.5

Determine Team Velocity: "Velocity is a measure of the amount of work a Development Team can accomplish in a single Sprint... It is calculated at the end of the Sprint by totaling the story points for all fully completed User Stories." This directly supports that velocity is the total number of completed story points.

2. Hoda

R.

& Noble

J. (2017). Becoming Agile: A Grounded Theory of Agile Transitions in Practice. Proceedings of the 39th International Conference on Software Engineering (ICSE '17). IEEE Press

141–151.

Section 4.2.2

Metrics: The paper discusses how teams use velocity for planning and defines it as "the number of story points completed per iteration." This aligns with the correct answer and distinguishes it from measures of time or commitment percentages. DOI: https://doi.org/10.1109/ICSE.2017.21

3. Layton

M. C. (2012). Agile Project Management For Dummies. John Wiley & Sons.

Chapter 10

Forecasting and Communicating Progress: The text explains

"Velocity is the total number of story points from all the completed stories in a given sprint." This definition

from a widely recognized academic and professional resource

confirms that velocity is a sum of points from completed work.

The Scrum of Scrums (SoS) meeting is a mechanism for coordinating multiple Scrum Teams working on a large project. According to the Scrum Body of Knowledge (SBOK® Guide), which is the primary reference for the ScrumStudy SMC certification, this meeting has a defined structure. Representatives from each team attend the SoS meeting and answer four specific questions to ensure alignment and address inter-team dependencies. The options A, B, C, and D correspond exactly to these four standard questions, which cover past progress, upcoming plans, existing impediments related to dependencies, and potential future impacts on other teams. Therefore, all listed questions are answered in the meeting.

A. C and D: This option is incorrect because it omits the questions regarding what the team has been working on (A) and what they will do next (B), which are essential for context and planning.

B. A and B: This option is incorrect as it leaves out the critical questions about unfulfilled dependencies (C) and potential impacts on other teams (D), which are the primary reasons for the meeting.

C. A, B, and D: This option is incorrect because it excludes the question about what other teams were counting on that remains undone (C), a key element for identifying and resolving impediments.

1. SCRUMstudy. (2017). A Guide to the Scrum Body of Knowledge (SBOK® Guide) (3rd ed.). VMEdu

Inc.

Reference Details: Chapter 7: Scale Scrum to Large Projects

Section 7.4: Scrum of Scrums Meeting. This section explicitly lists the four questions that are asked during the Scrum of Scrums meeting:

1. What has my team been working on since we last met?

2. What will my team do until we meet again?

3. What were other teams counting on our team to finish that remains undone?

4. What is our team planning to do that might affect other teams?

This directly validates that options A

B

C

and D are all correct.