1.3 Scrum Values and Accountabilities in Product Decision Making

1.3 Scrum Values and Accountabilities in Product Decision Making

Quick Answer: The five Scrum Values (Courage, Focus, Openness, Respect, Commitment) are not decorative posters on an office wall; they are the essential ethical and operational guidelines for making difficult product trade-offs. In Scrum, authority is decentralized into three distinct accountabilities: the Product Owner (maximizes value and owns the Product Backlog), the Developers (create usable Increments and own the 'how' and quality), and the Scrum Master (fosters team effectiveness and Scrum adherence). When these boundaries blur, empirical product management collapses.

---

The Five Scrum Values Through the Strategic PO Lens

In complex environments, rules cannot foresee every operational dilemma. When market pressures mount, stakeholders clash, or technical hurdles arise, the Scrum Values guide decision making:

+-------------------------------------------------------------------------+
|                        THE FIVE SCRUM VALUES                            |
+-------------------------------------------------------------------------+
|  COURAGE    | Say "No" to waste; kill failing features; embrace truth.  |
|  FOCUS      | One Product Goal; protect the Sprint Goal; limit WIP.     |
|  OPENNESS   | Transparent telemetry; expose bad metrics; welcome debate.|
|  RESPECT    | Honor Developers' 'how'; treat users as humans, not KPIs. |
|  COMMITMENT | Commit to goals and quality; reject shortcut compromises. |
+-------------------------------------------------------------------------+

1. Courage: The Foundation of Value Maximization

For an advanced Product Owner, Courage is the most critical value. It manifests in high-stakes moments:

• The Courage to Say "No": Saying "No" (or "Not now") to senior executives, influential sales leaders, or key customers whose requests do not align with the Product Goal. Every time a PO says "Yes" to a low-value feature, they inadvertently say "No" to the core strategic outcome.
• The Courage to Terminate Sunk Costs: Admitting when a highly publicized, expensive product hypothesis has failed in the market. Instead of persevering to save face, the PO terminates the initiative immediately to preserve organizational capital.
• The Courage to Release Early: Exposing an unpolished MVP or pretotype to real users to validate assumptions, resisting the urge to hide behind endless internal review cycles.

2. Focus: Eliminating Cognitive and Product Debt

Focus protects the Scrum Team from the chronic disease of multitasking and feature creep:

• Focus on the Product Goal: Resisting the temptation to transform the Product Backlog into a grab-bag of miscellaneous departmental requests. Every item refined should trace a direct path to the current Product Goal.
• Protecting the Sprint Goal: Ensuring the Developers have the uninterrupted cognitive space to deliver a cohesive Increment that satisfies the Sprint Goal without being derailed by daily stakeholder emergencies.

3. Openness: Embracing Uncomfortable Market Truths

Empiricism depends on complete visibility into reality, especially when reality is disappointing:

• Openness with Telemetry and Bad News: Transparently sharing negative product metrics—such as poor retention, high drop-off rates, or declining customer satisfaction—with stakeholders during the Sprint Review.
• Openness to Collaboration: Listening actively when Developers propose simpler, alternative technical approaches that deliver 80% of the customer value for 20% of the implementation effort.

4. Respect: Honoring Self-Management and User Needs

Respect establishes healthy professional boundaries across the organization:

• Respecting Developer Autonomy: Recognizing that Developers are skilled professionals who own technical design, estimates, and task management. The PO never dictates how to build or cuts corners on the Definition of Done.
• Respecting Stakeholders: Acknowledging stakeholders' business pressures and domain expertise while maintaining unambiguous ownership of the Product Backlog ordering.
• Respecting Customers: Building software that genuinely solves customer problems rather than deploying deceptive design patterns ("dark patterns") to artificially boost engagement.

5. Commitment: Dedication to Goals and Quality

In the 2020 Scrum Guide, Commitment was clarified: team members commit to achieving goals and supporting each other, rather than committing to fixed scope and predictive deadlines:

• Commitment to the Product Goal & Sprint Goal: The PO commits to delivering value and solving customer problems, retaining flexibility regarding which specific PBIs are built to fulfill that goal.
• Commitment to Quality: Refusing to compromise the Definition of Done or release technical debt to satisfy an artificial commercial milestone.

---

Boundary Lines: The Three Scrum Accountabilities

The 2020 Scrum Guide intentionally replaced the word "roles" with "accountabilities" to emphasize that Scrum is comprised of specific responsibilities, not corporate job titles or status hierarchies. There are no sub-teams or hierarchies within a Scrum Team—it is a unified unit of professionals focused on one Product Goal.

                       +------------------------+
                       |       SCRUM TEAM       |
                       +-----------+------------+
                                   |
        +--------------------------+--------------------------+
        |                          |                          |
        v                          v                          v
+---------------+          +---------------+          +---------------+
| PRODUCT OWNER |          |  DEVELOPERS   |          | SCRUM MASTER  |
| Maximizes     |          | Create Usable |          | Fosters Team  |
| Product Value |          | Increments;   |          | Effectiveness |
| & Owns PB     |          | Own the 'How' |          | & True Leader |
+---------------+          +---------------+          +---------------+

Product Owner: The Value Maximizer

• Core Accountability: Maximizing the value of the product resulting from the work of the Scrum Team.
• Key Responsibilities: Developing and explicitly communicating the Product Goal; creating, ordering, and clearly expressing Product Backlog items; ensuring the Product Backlog is transparent, visible, and understood.
• Decision Mandate: The Product Owner is one person, not a committee. For the PO to succeed, the entire organization must respect their decisions. These decisions are reflected in the content and ordering of the Product Backlog.

Developers: The Creators of Quality Increments

• Core Accountability: Creating a usable, functional Increment each Sprint that adheres to the Definition of Done.
• Key Responsibilities: Creating the plan for the Sprint (the Sprint Backlog); instilling quality by adhering to the Definition of Done; adapting their plan daily toward the Sprint Goal at the Daily Scrum; holding each other accountable as professionals.
• Decision Mandate: The Developers have exclusive authority over technical implementation, engineering practices, sizing, and task decomposition. No one—including the PO or Scrum Master—can tell them how to turn Product Backlog items into Increments of value.

Scrum Master: The Effectiveness Leader

• Core Accountability: Establishing Scrum as defined in the Scrum Guide and fostering the Scrum Team's overall effectiveness.
• Key Responsibilities: Coaching team members in self-management and cross-functionality; helping the Product Owner find techniques for effective Product Goal definition and backlog management; removing organizational impediments; facilitating stakeholder collaboration; protecting the team from outside disruption.
• Decision Mandate: The Scrum Master is a true leader who serves the Scrum Team and the broader organization. They possess process authority, not managerial authority.

---

Comprehensive Comparison Matrix of Accountabilities

The table below details the division of responsibilities across the three accountabilities:

---

Pervasive Anti-Patterns in Product Organizations

Exam scenarios frequently depict dysfunctional organizations. To score highly on PSPO II, you must quickly identify these organizational anti-patterns:

Anti-Pattern 1: The PO as Architectural Dictator or Task Micromanager

• Symptom: A PO with a technical background dictates specific database schemas, assigns tasks to individual developers, or tells the team to bypass automated testing to meet a deadline.
• Harm: Violates Respect and destroys self-management. Developers lose ownership of code quality, leading to rampant technical debt and demoralization.
• Correction: The PO must constrain their input to the business problem, acceptance criteria, and expected user value, allowing Developers full autonomy over technical design.

Anti-Pattern 2: Developers Bypassing the PO to Build Rogue Features

• Symptom: Developers accept side-channel requests from favorite stakeholders or spend Sprints refactoring infrastructure that has no bearing on the Product Goal without PO knowledge.
• Harm: Destroys Focus, undermines the Product Goal, and conceals true capacity from the organization.
• Correction: The Scrum Master and PO reinforce that all work entering the Sprint must support the Sprint Goal or trace back to an ordered Product Backlog item.

Anti-Pattern 3: The Scrum Master as Command-and-Control Project Manager

• Symptom: An SM acts as a boss: assigning user stories to developers, running the Daily Scrum as a status report, and updating Gantt charts for management.
• Harm: Destroys self-management and reduces team members to passive ticket-takers.
• Correction: The SM transitions to a coaching stance, encouraging Developers to run their own Daily Scrum and self-manage task distribution.

Anti-Pattern 4: The Proxy Product Owner / Order Taker

• Symptom: The designated PO is merely a Business Analyst or project coordinator who collects feature requests from true business decision-makers (e.g., a steering committee) and writes user stories without authority to make trade-offs.
• Harm: Slows decision-making to a crawl, creates massive handoffs, and prevents empirical value maximization.
• Correction: The organization must empower the PO with budget and strategic authority, or appoint the true decision-maker directly into the Product Owner accountability.