10.1 Scrum Framework

10.1 Scrum Framework

Scrum is a lightweight framework co-created by Ken Schwaber and Jeff Sutherland. Defined in the official Scrum Guide, Scrum is a lightweight framework designed to help teams generate value through adaptive solutions for complex problems. At its core, Scrum relies on empiricism—the knowledge that knowledge comes from experience and making decisions based on what is observed—and lean thinking, which reduces waste and focuses on essentials.

The Empirical Pillars and 3 Scrum Accountabilities

Empirical process control in Scrum is sustained by three structural pillars: Transparency (emerging work and process must be visible to those performing and receiving the work), Inspection (artifacts and progress must be inspected frequently to detect undesirable variances), and Adaptation (processes or materials should be adapted as soon as possible if an inspection reveals deviation beyond acceptable limits).

The Scrum framework defines three specific accountabilities within a single Scrum Team, typically comprising 10 or fewer people to maximize communication efficiency:

1. Product Owner (PO)

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. Key responsibilities include:

• Developing and explicitly communicating the Product Goal.
• Creating, ordering, and clearly communicating Product Backlog items.
• Ensuring that the Product Backlog is transparent, visible, and understood by all.
• The organization should respect Product Owner decisions, as made visible through backlog content and ordering; the PO is a single person, not a committee.

2. Scrum Master (SM)

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide by helping everyone understand Scrum theory and practice. The Scrum Master is a true leader who serves the Scrum Team and the larger organization:

• Coaching team members in self-management and cross-functionality.
• Causing the removal of impediments to the Scrum Team's progress.
• Ensuring that all Scrum events take place and are positive, productive, and kept within their timeboxes.
• Helping the organization adopt Scrum and navigate complex organizational change.

3. Developers

Developers are the professionals in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. Regardless of individual job titles (e.g., QA engineer, UI designer, software developer), all team members contributing to the increment are called Developers:

• Creating a plan for the Sprint (the Sprint Backlog).
• Instilling quality by adhering to a Definition of Done.
• Adapting their plan each day toward the Sprint Goal.
• Holding each other accountable as professionals.

The 5 Scrum Events & Timeboxing Rules

Scrum structures work into five formal events for inspection and adaptation. Every event in Scrum is a timebox—a fixed maximum duration that cannot be extended. Timeboxing prevents Parkinson's Law (work expanding to fill available time) and enforces regular feedback loops.

+-----------------------------------------------------------------------------------+
|                                  THE SPRINT                                       |
|                            (One Month or Less)                                |
|                                                                                   |
|  +-------------------+   +-----------------+   +------------------+   +----------+|
|  |  Sprint Planning  |-->|   Daily Scrum   |-->|  Sprint Review   |-->| Retrospect||
|  | (Max 8 hrs/month) |   | (15 mins/day)   |   | (Max 4 hrs/month)|   | (3 hrs)  ||
|  +-------------------+   +-----------------+   +------------------+   +----------+|
+-----------------------------------------------------------------------------------+

1. The Sprint (Container Event)

The Sprint is the heartbeat of Scrum, where ideas are turned into value. Sprints are fixed-length events of one month or less (commonly 2 weeks in industry practice) to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint. During a Sprint:

• No changes are made that would endanger the Sprint Goal.
• Quality does not decrease.
• The Product Backlog is refined as needed.
• Scope may be clarified and renegotiated between the Product Owner and Developers as more is learned.

2. Sprint Planning

Sprint Planning initiates the Sprint by laying out the work to be performed. It is timeboxed to a maximum of 8 hours for a one-month Sprint and is usually shorter for shorter Sprints; the Scrum Guide does not prescribe an exact proportional timebox. Sprint Planning addresses three topics:

1. Topic One: Why is this Sprint valuable? The Product Owner proposes how the product could increase its value and utility, and the team collaboratively defines the Sprint Goal.
2. Topic Two: What can be Done this Sprint? Developers select items from the Product Backlog to include in the current Sprint based on capacity and past performance.
3. Topic Three: How will the chosen work get done? Developers plan the work necessary to build an Increment that meets the Definition of Done.

3. Daily Scrum

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team held every working day of the Sprint. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, creating an actionable plan for the next 24 hours. It is not a status report to management or the Scrum Master.

4. Sprint Review

The Sprint Review is held at the end of the Sprint to inspect the outcome of the Sprint and determine future adaptations. Timeboxed to a maximum of 4 hours for a one-month Sprint and usually shorter for shorter Sprints, the Scrum Team and stakeholders review what was accomplished and what changed in the environment. The Scrum Team and stakeholders discuss progress toward the Product Goal, changes in the environment, and what to do next; the Product Backlog may be adjusted.

5. Sprint Retrospective

The Sprint Retrospective concludes the Sprint. Timeboxed to a maximum of 3 hours for a one-month Sprint and usually shorter for shorter Sprints, its purpose is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went regarding individuals, interactions, processes, tools, and their Definition of Done, identifying actionable improvements for the next Sprint.

Scrum Artifacts & Their 3 Commitments

Scrum defines three Artifacts to represent work or value. Each artifact contains a specific Commitment to ensure transparency and measure progress against defined benchmarks:

Product Backlog  -----> Commitment: Product Goal
Sprint Backlog   -----> Commitment: Sprint Goal
Increment        -----> Commitment: Definition of Done

1. Product Backlog & The Product Goal

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.

• Commitment: Product Goal. The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Scrum Team must fulfill (or abandon) one Product Goal before taking on the next.

2. Sprint Backlog & The Sprint Goal

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

• Commitment: Sprint Goal. The Sprint Goal is the single objective for the Sprint. It creates coherence and focus, encouraging the team to work together rather than on separate initiatives. If the work turns out to be different than expected, Developers collaborate with the Product Owner to adjust the scope without changing the Sprint Goal.

3. Increment & The Definition of Done (DoD)

An Increment is a concrete stepping stone toward the Product Goal. Multiple Increments may be created within a Sprint, and each must be usable and meet the Definition of Done.

• Commitment: Definition of Done (DoD). The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. If an item does not meet the DoD, it cannot be released or presented at the Sprint Review; instead, it returns to the Product Backlog.

The 5 Scrum Values

Empirical process control requires a culture built on five core Scrum Values:

1. Commitment: The Scrum Team commits to achieving its goals and supporting each other.
2. Courage: Team members have the courage to do the right thing and work on tough problems.
3. Focus: Everyone focuses on the work of the Sprint and the goals of the Scrum Team.
4. Openness: The Scrum Team and its stakeholders agree to be open about all the work and challenges.
5. Respect: Team members respect each other to be capable, independent people.

Exam Application: Scrum Value Scenarios

On the PMI-ACP exam, scenarios often test how Scrum Values resolve team conflicts:

• If management pressures a team to add items mid-Sprint, the team demonstrates Courage and Focus by rejecting scope changes that jeopardize the Sprint Goal.
• If a developer discovers technical debt that slows progress, Openness demands raising the issue immediately in the Daily Scrum rather than concealing it.