12.3 Stakeholder Collaboration Patterns

12.3 Stakeholder Collaboration Patterns

Knowing who stakeholders and customers are is useless if collaboration is broken. PSPO I tests how stakeholders engage with the Scrum Team and Product Owner: frequent and transparent, or political and opaque. Healthy patterns produce better Product Goals, better order, and better value. Anti-patterns produce shadow backlogs, fake demos, and ignored empiricism.

---

Frequent Collaboration, Not Annual Surprises

Scrum is built for complex work where knowledge emerges. Stakeholders and customers should collaborate frequently so assumptions die young and value hypotheses get evidence.

Collaboration is not endless meetings for their own sake. It is timely access to people who hold needs, constraints, and outcome feedback—through Reviews, refinement conversations, interviews, support signals, beta use, and release feedback.

---

Sprint Review: Primary Formal Collaboration Moment (Not the Only One)

Scrum Guide 2020: 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… The Product Backlog may also be adjusted to meet new opportunities.

Why Review is primary and formal

This is the Guide’s formal event designed for stakeholder collaboration around the Increment. PSPO I expects you to protect its purpose: real Done work, real stakeholders, real backlog adaptation—not a PowerPoint progress report with no Increment.

Review is not the only collaboration

Exam trap: “Stakeholders may only speak at Sprint Review.” False—Review is the primary formal Increment inspection with stakeholders, not a gag order for the rest of the Sprint. Opposite trap: “Skip Review because we chat in Slack.” Informal chat does not replace inspecting a Done Increment with key stakeholders and adapting the backlog transparently.

Review is not a release gate

Collaboration at Review must not be confused with release control. A Done Increment may be released before Review when value warrants. Stakeholders inspect outcomes; they do not become a change-approval board that freezes Done value until a ceremony.

---

Scrum Master Facilitates Stakeholder Collaboration as Requested or Needed

Scrum Guide 2020: The Scrum Master serves the Product Owner in several ways, including… Facilitating stakeholder collaboration as requested or needed.

As requested or needed means facilitation is service to effectiveness—not permanent ownership of stakeholder relationships that replaces Product Owner accountability for value synthesis and ordering.

---

Changing the Product Backlog: Convince the Product Owner

Scrum Guide 2020: The Product Owner may… [manage the Product Backlog] or may delegate… Regardless, the Product Owner remains accountable… The Product Owner is one person, not a committee… Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

This sentence is high-yield for collaboration scenarios.

Healthy change path

1. Stakeholder has a new need, risk, or opportunity.
2. They engage the Product Owner with evidence and desired outcomes.
3. Product Owner decides whether and where it belongs in the ordered Product Backlog (and whether it affects Product Goal).
4. Transparency means the change is visible—not a private promise.
5. Developers pull work from the ordered backlog (via Sprint Planning / Sprint Backlog), not from hallway assignments.

Unhealthy change paths

Collaboration includes disagreement. Stakeholders may passionately advocate. The decision remains with the Product Owner. The Scrum Master may facilitate the conversation and coach the organization—not take the decision away.

---

Transparent Increment Enables Informed Adaptation

Stakeholder collaboration only improves the product when people inspect reality.

If the team demos half-finished work as complete, stakeholders “adapt” based on lies—then blame Scrum when production fails. Protecting the Definition of Done is a collaboration practice, not only an engineering practice.

---

Collaboration Patterns (Positive Playbook)

Pattern 1: Review as a working session

• Invite key stakeholders (not only friendly ones).
• Inspect the Increment and Product Goal progress.
• Capture backlog adaptations with the Product Owner deciding order.
• Avoid turning it into a performance review of Developers.

Pattern 2: Continuous discovery with PO synthesis

• Talk to users/customers between Reviews.
• Bring insights into refinement and ordering.
• Keep one backlog—discovery does not create a second secret list of promises.

Pattern 3: SM-enabled stakeholder health

• When Reviews are empty or toxic, SM facilitates improvement.
• When stakeholders bypass the PO, SM coaches the organization while PO reasserts the backlog.

Pattern 4: Transparent “no” / “not yet”

• PO explains order relative to Product Goal and value.
• Stakeholder may disagree and return with better evidence.
• Respect and openness beat false agreement.

Pattern 5: Multi-team, one product

• Stakeholders still convince one Product Owner.
• One Product Backlog remains the collaboration surface.
• Do not invent a Product Owner per stakeholder group for the same product.

---

Anti-Patterns (Memorize for Scenario Questions)

1. Stakeholders bypass the Product Owner

Symptom: Directors give work directly to Developers; “urgent” interrupts the Sprint without PO negotiation.
Fix: Work enters through the Product Owner and Product Backlog; mid-Sprint changes are negotiated against the Sprint Goal; SM helps remove the organizational bypass.

2. Private side agreements

Symptom: PO or Developers promise a feature offline that never appears transparently on the backlog or appears with fake low visibility.
Fix: All commitments that consume capacity are visible in the ordered Product Backlog; side deals are cancelled as anti-transparency.

3. No Review attendance / Review theater

Symptom: Key stakeholders never attend; Review is a slide deck; no backlog adaptation.
Fix: Make Review valuable (real Increment, clear Goal progress); SM facilitates and coaches attendance; PO uses the event to adapt order—not to perform.

4. Stakeholders as multiple Product Owners

Symptom: “Business PO,” “Tech PO,” “Compliance PO” each order work for one product.
Fix: One Product Owner; others are stakeholders who convince the PO; compliance needs are represented in the single backlog.

5. Collaboration without Done

Symptom: Stakeholders applaud demos of undone work; production is a surprise.
Fix: Only Done counts; Review inspects outcomes that meet the Definition of Done.

6. PO hides from stakeholders

Symptom: PO avoids hard conversations; Developers absorb all political heat.
Fix: PO develops and communicates direction, represents needs, and owns ordering decisions courageously; SM may facilitate but does not replace the PO.

---

Scenario Drill

Scenario: A compliance stakeholder skips Sprint Reviews for three months, then demands an emergency multi-Sprint initiative mid-Sprint by emailing Developers. Sales already extracted a private promise from a Developer for a demo feature. The Sprint Goal is still valid.

Sound collaboration response:

1. Developers do not accept a second backlog via email; they surface the request to the Product Owner and protect the Sprint plan/Goal conversation.
2. Product Owner takes both compliance and sales needs as stakeholder input, represents them on the Product Backlog, and orders for value/risk relative to the Product Goal—compliance risk may rightly rank high, but not by bypass magic.
3. Private sales promise is made transparent and re-ordered honestly (often lower if it does not serve Goal/value).
4. Mid-Sprint: negotiate only what serves the current Sprint Goal; large new initiative is backlog/ordering, not silent Sprint stuffing.
5. Scrum Master facilitates better stakeholder collaboration going forward—Review attendance, proper intake path, coaching against bypass.
6. Future Sprint Reviews include the compliance stakeholder with Done Increments so adaptation is continuous, not quarterly panic.

That package—frequent formal and informal collaboration, Review integrity, SM facilitation, convince-the-PO rule, transparent Increment—is the stakeholder collaboration standard PSPO I expects.

---

Quick Self-Check

• Collaborate with stakeholders and customers frequently
• Sprint Review = primary formal Increment collaboration; not the only collaboration; not a release gate
• SM facilitates stakeholder collaboration as requested/needed
• Want to change the PB? Convince the Product Owner
• Transparent Done Increment enables informed adaptation
• Anti-patterns: bypass, side agreements, empty/fake Reviews, multi-PO stakeholders, undone demos