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.