The Scrum framework is designed around a consistent and predictable rhythm, known as a cadence. Sprints are the heartbeat of this rhythm. According to the Scrum Guide, "A new Sprint starts immediately after the conclusion of the previous Sprint." This continuous cycle of Sprints, without any gaps in between, ensures that the Scrum Team maintains momentum, focus, and a steady pace of delivering value. The conclusion of one Sprint's Retrospective is immediately followed by the next Sprint's Planning event, creating a seamless flow.

A. Waiting for customer acceptance testing introduces a delay and a waterfall-style phase gate, which is contrary to the iterative nature of Scrum.

B. Relying on external approval from an architect creates a dependency that undermines the Scrum Team's self-management and autonomy, causing unnecessary delays.

D. The selection of Product Backlog items occurs during Sprint Planning, which is the very first event within a new Sprint, not a prerequisite for starting it.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. p. 8. "Sprints are the heartbeat of Scrum

where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint."

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. https://doi.org/10.1016/j.jss.2016.01.004. While focused on the Daily Scrum

this study discusses the importance of rhythm and routine in Agile practices (p. 119)

which is established by the unwavering

back-to-back cadence of Sprints.

3. MIT Sloan School of Management. (2016). 15.S63: Advanced Management & Leadership - Session 3: Agile at Scale. MIT OpenCourseWare. The course materials illustrate the Scrum process as a continuous cycle

where the output of one Sprint (Retrospective) flows directly into the input of the next (Sprint Planning)

reinforcing the principle of immediate succession.

The Scrum framework emphasizes the value of stable, long-lived teams. A consistent team composition allows members to build trust, develop effective communication patterns, and optimize their collaborative processes, leading to higher performance over time (as described by models like Tuckman's stages of group development). However, the framework is pragmatic. Changes in personnel are sometimes unavoidable. The most effective approach is to make changes only when necessary ("as needed") while acknowledging the predictable, short-term negative impact on productivity. This disruption occurs as the team adjusts its dynamics and integrates the new member(s). This aligns with Scrum's core principle of empiricism and transparency.

A. Changing the team every Sprint would create constant disruption, preventing the team from ever moving beyond the initial "forming" and "storming" stages, thus severely hindering productivity.

B. Ignoring the productivity impact of a team change is unrealistic and violates the Scrum value of transparency. The team's capacity and forecast will be affected.

C. The stance "never" is too rigid and impractical for any real-world organization where personnel changes are a fact of life due to attrition, promotions, or other factors.

1. The Scrum Guide (2020) by Ken Schwaber and Jeff Sutherland.

Reference: Page 5

"The Scrum Team" section. The guide defines the Scrum Team as a "cohesive unit of professionals." Frequent changes disrupt this cohesion

which is the foundation of a self-managing and effective team. While not explicitly stating "productivity reduction

" the emphasis on cohesion implies it.

2. Takeuchi

H.

& Nonaka

I. (1986). The New New Product Development Game. Harvard Business Review

64(1)

137-146.

Reference: Section "Built-in Instability". This foundational article for Scrum highlights that while the project is challenging

the project team itself should be "kept stable throughout." Stability is presented as a key condition for success.

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

Reference: Section 4.2

"Team stability". The study notes that "team stability is important for team performance" and that changes in team composition can cause the team to revert to earlier

less productive stages of development. (DOI: https://doi.org/10.1016/j.infsof.2009.11.004)

The Scrum Master is accountable for ensuring Scrum is understood and enacted correctly within the organization. The IT manager's request for a traditional status report indicates a misunderstanding of how progress is made transparent in Scrum. The Scrum Master's most effective action is to coach the manager, explaining that empirical progress is demonstrated by inspecting a tangible, "Done" Increment during the Sprint Review. This addresses the root cause of the request, educates the stakeholder, and protects the team from wasteful interruptions that do not contribute to the Sprint Goal, thereby upholding Scrum principles.

A. Tell the Developers to fit the report into the Sprint Backlog.

This treats a non-value-adding interruption as legitimate work, distracting the Developers from their primary focus of creating a valuable Increment and achieving the Sprint Goal.

B. Ask the Product Owner to send the manager the report.

This merely shifts the wasteful task to another team member and fails to address the manager's fundamental misunderstanding of Scrum's empirical nature.

C. Create and deliver the report to the manager herself.

This positions the Scrum Master as an administrative assistant rather than a coach and leader, reinforcing outdated practices and preventing the organization from properly adopting Scrum.

D. Tell the Scrum Team to figure it out themselves.

This is an abdication of the Scrum Master's responsibility to remove impediments and coach the organization, especially when the issue stems from a stakeholder external to the team.

1. Schwaber

K.

& Sutherland

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

Page 7

"Scrum Master": "The Scrum Master serves the organization in several ways

including: Leading

training

and coaching the organization in its Scrum adoption; ... Helping employees and stakeholders understand and enact an empirical approach for complex work". This directly supports coaching the IT manager (Option E).

Page 10

"Sprint Review": "The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed." This identifies the correct forum for stakeholders to understand progress.

2. Verwijs

C.

Russo

D.

& Gorschek

T. (2022). The role of the Scrum Master: a systematic literature review. PeerJ Computer Science

8

e1087.

Section "Identified activities"

Table 2: The paper identifies "Protecting the team" (including shielding from external interferences) and "Teaching

Mentoring

and Coaching" (including coaching stakeholders) as core Scrum Master activities. Option E is a direct application of these responsibilities

whereas options A

B

and C are contrary to them. (https://doi.org/10.7717/peerj-cs.1087)

The Definition of Done (DoD) is a formal description of the state of the Increment when it meets the quality measures required for the product. Its primary purpose is to create transparency. By ensuring that all Developers adhere to the DoD, the Product Owner and all stakeholders have a clear, shared understanding of what work was completed during the Sprint. This transparency is essential for effective inspection of the Increment at the Sprint Review, which in turn allows for adaptation of the Product Backlog and informed decision-making about the product's future direction and potential release.

A. While a consistent DoD can lead to more predictable delivery and help in forecasting, its primary purpose is ensuring a transparent and shared understanding of the Increment's quality and completeness.

C. The DoD applies to the quality of the Increment within a single Sprint; it does not serve as a tool for guaranteeing deliverables over multiple future Sprints, as the Product Backlog is emergent.

D. This describes a dysfunctional, command-and-control behavior. Scrum operates on trust and collaboration, not reprimand. Velocity is a planning tool for the Developers, not a performance metric for management.

---

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. p. 9. "The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done

it cannot be released or even presented at the Sprint Review."

2. Ceschi

M.

Sillitti

A.

& Succi

G. (2019). The Definition of Done: A Reference for Practitioners and Researchers. In Agile Processes in Software Engineering and Extreme Programming – Workshops (pp. 279-286). Springer

Cham. DOI: https://doi.org/10.1007/978-3-030-30126-233. The paper states

"The DoD is a key element to ensure transparency and a common understanding of the quality of the delivered increment among all the stakeholders." (Section 2

Paragraph 1).

3. University of Virginia Darden School of Business. (n.d.). Agile Development in Practice. Coursera. In Module 1

"Getting Started with Agile

" the course materials emphasize that artifacts like the Definition of Done are designed to maximize transparency

which is a pillar of the empirical process control theory upon which Scrum is founded.

Scrum does not use a traditional, static project plan. Instead, the Product Backlog serves as the single, authoritative plan for the product. It is an emergent and dynamic artifact that evolves throughout the product's lifecycle. The Product Owner is responsible for managing this backlog, which involves continuously updating and re-ordering it as new information, market feedback, and stakeholder insights become available. This ensures the plan always reflects the most current understanding of what is needed to maximize the product's value.

A. The Product Owner prepares the Product Backlog for Sprint Planning, but the Developers determine how much work they can take on; the PO does not dictate a plan for the Sprint's volume.

C. The Daily Scrum is a planning event for the Developers to inspect progress toward the Sprint Goal. It is not a designated time for the Product Owner to update the overall product plan.

D. The Sprint Retrospective is focused on inspecting the Scrum Team's process and effectiveness, not on updating the Product Backlog or product plan.

1. Schwaber

K.

& Sutherland

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

Page 11

"Product Backlog" section: "The Product Backlog is an emergent

ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team." This establishes the Product Backlog as the plan.

Page 12

"Product Backlog" section: "The Product Backlog is a living artifact... Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details

such as a description

order

and size." This confirms its continuous

emergent nature.

2. Hohl

P.

Klünder

J.

van Bennekum

A.

et al. (2018). Backlog Refinement in Large-Scale Agile System Development. In: Product-Focused Software Process Improvement. PROFES 2018. Lecture Notes in Computer Science

vol 11271. Springer

Cham.

Page 1

Abstract: "The product backlog is the central planning artifact in Scrum..." This academic source confirms the role of the Product Backlog as the primary plan in the Scrum framework. (DOI: https://doi.org/10.1007/978-3-030-03673-723)

The Scrum framework operates on a consistent and predictable cadence. Sprints are consecutive, fixed-length events that form the heartbeat of Scrum. To maintain this rhythm and avoid creating gaps in the development process, a new Sprint begins immediately after the previous Sprint concludes. The conclusion of a Sprint is marked by the Sprint Retrospective, and the start of the next is marked by Sprint Planning. This continuous cycle ensures a steady flow of value delivery and provides a regular opportunity for inspection and adaptation.

A. Sprints are not tied to specific calendar days like Monday. The cadence is continuous, regardless of the day of the week.

C. Sprint Planning is the very first event within a Sprint. Therefore, the Sprint must have already started for Sprint Planning to occur.

D. The start of a Sprint is dictated by the Scrum framework's cadence, not an individual's readiness, to ensure predictability and rhythm.

---

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. p. 8. "Sprints are the heartbeat of Scrum

where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint."

2. Sutherland

J.

& Sutherland

J. J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business. In Chapter 4

"Time

" the authors emphasize the importance of a regular

uninterrupted rhythm

stating

"Once you decide how long a Sprint should be

that’s it. It never changes... At the end of the Sprint

the team shows what they’ve built... The next day they start the next Sprint."

3. Stellman

A.

& Greene

J. (2014). Learning Agile: Understanding Scrum

XP

Lean

and Kanban. O'Reilly Media. In Chapter 11

"Scrum

" the Sprint cycle is described as continuous: "When one sprint ends

the next sprint begins." This reinforces the concept of no downtime between Sprints.

The Product Owner is accountable for maximizing the value of the product. Value is an outcome determined by the customer and user, not an internal measure of output. To ensure the product delivers value, the Product Owner must focus on evidence-based measures.

Feature usage (A) provides quantitative data on which parts of the product customers find useful.

Direct customer feedback (B) offers qualitative insights into user satisfaction, pain points, and needs.

Ease of adoption and use (C) directly impacts the customer's ability to realize the product's value.

These three elements provide a holistic view of the product's current value and guide the Product Owner in making decisions to enhance it.

D. Velocity is an internal team metric measuring output per Sprint, not the value or outcome delivered to the customer.

E. Scrum is founded on empiricism and adapting to change. Minimizing scope changes prevents the team from responding to new insights to maximize value.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. p. 5. The guide states

"The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team." This accountability necessitates a focus on value-centric measures

not internal metrics.

2. Scrum.org. (2020). The Evidence-Based Management Guide. pp. 6-8. This guide details Key Value Areas (KVAs) for measuring value. "Current Value" (CV) is a key KVA that is assessed through metrics like customer satisfaction

employee satisfaction

and customer usage index

which directly support options A

B

and C.

3. Maximini

D. (2015). The Scrum Culture: Introducing Agile Methods in Organizations. Springer International Publishing. p. 61. In the chapter on the Product Owner

it is emphasized that "The Product Owner is responsible for the value of the product... He is not responsible for the velocity of the team." This distinguishes the PO's focus on value (outcome) from team productivity (output). DOI: https://doi.org/10.1007/978-3-319-11827-7

The core principle at play is self-management. The Scrum Guide mandates that Scrum Teams are self-managing, meaning they determine how to best accomplish their work. The logistical arrangements for the Daily Scrum, an event owned by the Developers, fall squarely within this domain. The Scrum Master's role is to be a servant-leader who coaches the team in self-management and Scrum principles. Intervening by providing a solution or escalating the issue would undermine the team's autonomy and accountability. The most appropriate action is to empower the Developers to identify and implement their own solution, thereby strengthening their self-management capabilities.

B. Ask the Developers to alternate who is responsible for meeting setup.

This is a prescriptive solution. The Scrum Master should not dictate how the team solves its problems, as this undermines their self-management and ownership.

C. Set up the meeting and tell the Scrum Team that is how it will be done.

This is a command-and-control anti-pattern. It removes responsibility from the team and positions the Scrum Master as an administrator or manager, which contradicts their true role.

D. Inform management and ask them to solve it.

This is an inappropriate escalation. The team is fully capable of resolving this internal logistical issue. Escalating it disempowers the team and misrepresents the issue as an impediment they cannot solve.

1. Schwaber

K.

& Sutherland

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

Page 5

"Scrum Team" section: "Scrum Teams are self-managing

meaning they internally decide who does what

when

and how." This directly supports allowing the team to solve their own logistical problems.

Page 7

"Scrum Master" section: "The Scrum Master serves the Scrum Team in several ways

including: Coaching the team members in self-management and cross-functionality;" This defines the Scrum Master's coaching role rather than a directive one.

Page 9

"Daily Scrum" section: "The Daily Scrum is a 15-minute event for the Developers of the Scrum Team." This establishes the Developers' ownership of the event and

by extension

its logistics.

The Scrum framework is founded on the principle of self-management. The Developers are accountable for all aspects of creating a usable Increment each Sprint. This includes creating the plan for the Sprint (the Sprint Backlog) and tracking their own progress toward the Sprint Goal. The Daily Scrum is a key event specifically for the Developers to inspect progress and adapt their plan for the next 24 hours. This direct, daily management of their work ensures focus and adaptability, making them solely accountable for managing their progress within the Sprint.

B. Scrum does not recognize hierarchies like "junior" or "senior" within the Developers; the entire group is collectively accountable.

C. The Scrum Master is a facilitator and coach who ensures the team adheres to Scrum principles, but they do not manage the team's work.

D. The Product Owner is accountable for maximizing product value by managing the Product Backlog, not for managing the Developers' daily progress.

---

1. Schwaber

K.

& Sutherland

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

Page 6

"Developers" section: "The Developers are always accountable for: Creating a plan for the Sprint

the Sprint Backlog; ... Adapting their plan each day toward the Sprint Goal; and

Holding each other accountable as professionals."

Page 9

"Daily Scrum" section: "The Daily Scrum is a 15-minute event for the Developers of the Scrum Team... The Developers can select whatever structure and techniques they want

as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management."

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. https://doi.org/10.1016/j.jss.2016.01.004

Section 4.1

"Planning the day": The study identifies that the daily meeting is a core mechanism for the team to synchronize and manage its own work. It states

"The main purpose of the daily stand-up meeting is for the team members to coordinate their work for the next 24 h." This reinforces that the team (Developers) manages its own progress.

The Daily Scrum is a 15-minute event specifically for the Developers of the Scrum Team. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog for the upcoming day's work. According to the Scrum Guide, the Product Owner's participation is only required if they are also actively working on items in the Sprint Backlog. In this scenario, they are not participating as a Product Owner but as a Developer, contributing to the daily plan alongside the other Developers. Their input on the work they are performing is crucial for the team's synchronization.

A. The Scrum Master is a facilitator and coach; they do not have the authority to mandate the Product Owner's attendance at the Developers' event.

C. While impediments may be identified during the Daily Scrum, it is not a problem-solving meeting. The necessary conversations to resolve them typically happen after the Daily Scrum.

D. The Daily Scrum is a tactical planning event for Developers. Representing the stakeholder's view is a continuous activity for the Product Owner, not one specifically tied to this meeting.

1. Schwaber

K.

& Sutherland

J. (2020). The Scrum Guide. Scrum.org. Page 10

"Daily Scrum" section

states: "The Daily Scrum is a 15-minute event for the Developers of the Scrum Team... If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog

they participate as Developers."

2. Rubin

K. S. (2012). Essential Scrum: A Practical Guide to the Most Popular Agile Process. Addison-Wesley Professional. In Chapter 17

"The Daily Scrum

" it is clarified that the event is for the Development Team (now called Developers) to synchronize their work. Others may attend but only team members participate. This reinforces that participation is tied to being part of the team performing the work.