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.