01 — Understanding and Applying the Scrum Framework

This section targets: Empiricism, Scrum Values, Scrum Team, Events, Artifacts/Commitments.

Key Focus Areas from Professional Scrum Competencies:

• Empiricism
• Scrum Values
• Scrum Team
• Events
• Artifacts
• Done

Empiricism

Scrum is built on empiricism: making decisions based on what is known (observation and evidence), not long-range prediction. In Scrum, empiricism means solving complex problems through an exploratory process rather than predetermined plans.

Three pillars:

• Transparency: work and progress must be visible and understood by those responsible for the outcome.
• Inspection: frequent checks to detect undesirable variances. Must be done by skilled inspectors.
• Adaptation: adjust quickly when reality differs from expectation. Must happen as soon as possible to minimize deviation.

Leadership implication:

• Create an environment where bad news travels fast and is safe to share.
• Remove fear that causes people to hide reality.
• Use evidence to make decisions, not opinions or hierarchy.

Scrum Values (Deep Dive)

The Scrum Values—Commitment, Focus, Openness, Respect, Courage—create an environment where empiricism, self-management, and continual improvement thrive.

How each value manifests:

Commitment:

• The team commits to achieving goals and supporting each other
• Commitment is to outcomes, not fixed scope
• Leaders model commitment by removing impediments

Focus:

• Everyone focuses on the Sprint Goal and work of the Sprint
• Limit work in progress; avoid context switching
• Leaders protect focus by shielding teams from distractions

Openness:

• Be open about work, progress, and challenges
• Share learning and failures transparently
• Leaders model openness by admitting uncertainty

Respect:

• Respect team members as capable, independent people
• Respect different perspectives and expertise
• Leaders show respect by trusting teams to self-manage

Courage:

• Have courage to do the right thing and work on tough problems
• Courage to surface risks and bad news early
• Leaders create safety for courage by not punishing honesty

Leadership implication:

• Values are not posters; they show up in tradeoffs (e.g., courage to surface risk, openness to feedback, respect in conflict).
• As Gunther Verheyen notes: values must be lived, not just displayed.

Scrum Team (accountabilities)

Scrum Team is cross-functional and self-managing.

Accountabilities:

• Product Owner: maximize value, manage Product Backlog, clarify Product Goal.
• Scrum Master: enable Scrum, coaching, remove impediments, facilitate, help org adopt Scrum.
• Developers: create the Increment, own quality/DoD, plan the work in the Sprint.

Key idea:

• Authority and accountability must match. “Responsible without authority” creates dysfunction.

Scrum Events (Ceremonies)

Events exist to create regular inspection/adaptation loops and reduce the need for other meetings. Each event is an opportunity to inspect and adapt something. Skipping or shortening events reduces opportunities for inspection and adaptation.

The Sprint

The Sprint is the container event for all other events. It is the heartbeat of Scrum.

What happens during a Sprint:

• Sprint Planning occurs at the start
• Daily Scrums happen every day
• Development work occurs
• Sprint Review happens at the end
• Sprint Retrospective closes the Sprint

Leadership considerations:

• Protect the Sprint from scope creep and interruptions
• A new Sprint starts immediately after the previous Sprint ends
• Only the Product Owner can cancel a Sprint (if Sprint Goal becomes obsolete)

Sprint Planning

Sprint Planning initiates the Sprint by laying out the work to be performed.

Three topics addressed (Scrum Guide 2020):

1. Why is this Sprint valuable?

• Product Owner proposes how the product could increase value
• Scrum Team collaborates to define a Sprint Goal
• Sprint Goal must be finalized before the end of Sprint Planning

1. What can be Done this Sprint?

• Developers select items from the Product Backlog
• Developers forecast what can be accomplished
• PO helps clarify items and make tradeoffs

1. How will the chosen work get done?

• Developers plan work needed to create an Increment meeting the DoD
• Often decompose items into tasks of one day or less
• This is a forecast, not a commitment to specific tasks

Leadership considerations:

• Don't impose work on the team—they pull what they can commit to
• Ensure the Sprint Goal is clear and provides focus
• The Sprint Goal should be a single objective that creates coherence

Daily Scrum

The Daily Scrum is a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.

What it is NOT:

• ❌ A status meeting for managers
• ❌ A problem-solving session (take discussions offline)
• ❌ A report to the Scrum Master or Product Owner
• ❌ Three questions to answer mechanically

What it IS:

• ✅ A planning event owned by Developers
• ✅ Focused on progress toward the Sprint Goal
• ✅ An opportunity to identify impediments
• ✅ A chance to re-plan the day's work

Common formats:

• Walk the board (focus on work items, not people)
• Focus on Sprint Goal progress and blockers
• Whatever format the Developers choose that works

Leadership considerations:

• If you attend, observe silently—don't turn it into a status report
• If Developers are reporting TO someone, it's broken
• Get your updates from transparent artifacts, not Daily Scrum attendance
• Trust the team to self-manage their daily work

Sprint Review

The Sprint Review is a working session to inspect the Increment and adapt the Product Backlog.

What happens:

• Scrum Team presents what was accomplished (demonstrates the Increment)
• Stakeholders provide feedback
• Discussion of what to do next based on changes in business, market, timeline
• Product Backlog may be adjusted based on new insights
• Review of timeline, budget, and potential capabilities for next release

What it is NOT:

• ❌ A demo or presentation only
• ❌ A sign-off or approval gate
• ❌ A formality with no real discussion

What it IS:

• ✅ A collaborative working session
• ✅ An inspection point for stakeholders to see real progress
• ✅ A feedback loop that influences future work
• ✅ The primary mechanism for stakeholder engagement

Leadership considerations:

• Ensure stakeholders actually attend and engage
• Use this as THE forum for stakeholder feedback (not side channels)
• Protect the PO's authority to incorporate feedback into backlog ordering
• This is where transparency creates trust with stakeholders

Sprint Retrospective

The Sprint Retrospective is for the Scrum Team to inspect itself and create a plan for improvements.

What happens:

• Inspect how the last Sprint went (people, relationships, process, tools)
• Identify what went well and what could be improved
• Create actionable plan for implementing improvements
• Most impactful improvements are addressed as soon as possible

Key principles:

• Psychological safety is essential — people must feel safe to speak honestly
• Focus on the system, not blame individuals
• Improvements should be concrete and actionable
• At least one improvement should be implemented in the next Sprint

Common formats:

• Start/Stop/Continue
• What went well / What didn't / What to try
• 4Ls (Liked, Learned, Lacked, Longed for)
• Sailboat (wind = helps, anchors = holds back)
• Timeline retrospective

Leadership considerations:

• This is the engine of continuous improvement
• If teams skip retros, improvement stops
• Don't attend unless you're part of the Scrum Team
• Create conditions where people feel safe to raise issues
• Support teams in removing organizational impediments they identify

Event Summary Table

Why Each Event Matters for Leaders

Key insight: Leaders enable events to work by protecting their purpose, ensuring psychological safety, and acting on the feedback that emerges.

Artifacts + Commitments (Scrum Guide 2020)

The 2020 Scrum Guide introduced commitments for each artifact to enhance transparency and focus:

Product Goal (New in 2020)

• Describes a future state of the product
• Provides focus for the Scrum Team toward a larger valuable objective
• Only one Product Goal at a time, regardless of how many teams
• When achieved or abandoned, a new one is formulated

Sprint Goal

• The single objective for the Sprint
• Provides flexibility in the exact work needed
• Creates coherence and focus—team works together, not on separate initiatives
• Developers commit to the Sprint Goal

Definition of Done

• Shared quality standard for the Increment
• Creates transparency by providing a common understanding
• If not met, work cannot be released or presented at Sprint Review
• If organizational DoD exists, teams must follow it as a minimum

Leadership implication:

• Commitments create focus. Without them, teams drift into activity without outcomes.
• Commitments are mandatory in Scrum. Ignoring them means you're not doing Scrum.
• Leaders must protect commitments from being compromised under pressure.

Common “ScrumBut” smells

• “We do Scrum, but the Sprint Goal is optional.”
• “We do Scrum, but the PO is a requirements secretary.”
• “We do Scrum, but quality is a phase after development.”
• “We do Scrum, but the Daily Scrum is a manager status meeting.”

Scrum Guide 2020 Key Changes

Important changes to know for the exam:

1. Lean and less prescriptive: Removed prescriptive language, making Scrum more adaptable
2. Self-managing (not self-organizing): Teams decide who, how, and what to work on
3. Product Goal introduced: Long-term objective for the Product Backlog
4. Commitments for all artifacts: Each artifact now has a commitment
5. Sprint Planning has three topics: Why (Sprint Goal), What (items), How (plan)
6. One Scrum Team: No sub-teams or hierarchies; includes PO, SM, and Developers
7. Developers (not Development Team): Emphasizes individuals over team structure

Exam traps (how questions are usually framed)

• Events are not ceremonies. Pick answers that preserve inspection/adaptation for the right people (e.g., Daily Scrum is for Developers).
• The Increment must be inspectable. "Done later" breaks transparency and predictability.
• Scrum Team is self-managing. Answers that add control/assignment/reporting often conflict with the intent.
• Scrum roles are accountabilities. Watch for answers that turn the Scrum Master into a project manager or the PO into a scribe.
• Product Goal is mandatory. There must always be one Product Goal.
• Sprint Goal creates coherence. It's not optional—it's what the team is working toward together.