8.1 PO–Developer Collaboration
Key Takeaways
- The Product Owner collaborates with Developers to clarify Product Backlog items so intent, outcomes, and constraints are understood before and during the Sprint
- Scope may be renegotiated within a Sprint without endangering the Sprint Goal; Developers own how work is planned and executed
- Developers size the work; the Product Owner influences trade-offs and understanding of value, not effort estimates
- The Product Owner may delegate Product Backlog management work but remains solely accountable for value and effective backlog management
- The Product Owner does not tell Developers how to turn Product Backlog items into a Done Increment
8.1 PO–Developer Collaboration
Scrum Guide 2020 (Product Owner): The Product Owner may do the above work [Product Backlog management] or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
Scrum Guide 2020 (Developers): Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint… [They are accountable for] 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.
PSPO I frequently tests whether you can describe productive collaboration between the Product Owner and Developers without collapsing into either extreme: a detached “customer” who only shows up at demos, or a micromanager who runs the Sprint like a project lead. This section is the working relationship that makes empiricism possible—clear intent, honest sizing, protected Sprint Goals, and a firm WHAT/HOW boundary.
Why Collaboration Is Not Optional
Complex product work cannot be fully specified up front. Product Backlog items start as ideas about value and become usable Increments only through conversation, discovery, and adaptation. The Product Owner brings value context (Product Goal, stakeholder needs, ordering rationale, acceptance intent). Developers bring delivery reality (technical options, effort, risk, quality bar, capacity). Neither side alone can maximize value.
Collaboration shows up in:
| Moment | Product Owner contributes | Developers contribute |
|---|---|---|
| Refinement | Purpose, outcomes, constraints, ordering | Feasibility, splits, sizing, technical options |
| Sprint Planning | Ordered candidates, Sprint Goal value intent | Forecast of what can be Done, Sprint plan |
| During the Sprint | Clarification of intent; negotiate scope vs Goal | Self-managed plan, daily adaptation, DoD quality |
| Sprint Review | Stakeholder value conversation; backlog adaptation | Demonstrate Done work; surface technical insights |
If the Product Owner is unavailable, Developers invent intent or stall. If Developers are shut out of refinement, forecasts fail and the Increment misses the real outcome. Collaboration is a value practice, not a soft skill add-on.
Clarify Product Backlog Items
A core Product Owner accountability is creating and clearly communicating Product Backlog items. “Clearly” does not mean writing a 40-page specification alone. It means Developers can explain the desired outcome, constraints, and enough detail to build a Done Increment—or can name exactly what is still unknown.
What “clear enough” looks like
Clarity is relative to when the work will be done:
- Top of the Product Backlog (near-term Sprint candidates): refined enough that Developers can size with reasonable confidence and draft a Sprint plan.
- Lower backlog items: may be larger and less detailed; refinement continues over time.
- During the Sprint: remaining questions are answered quickly so the Sprint Goal is not blocked by PO silence.
Healthy clarification habits:
- State the outcome and why it matters relative to the Product Goal (not only a UI sketch).
- Surface constraints early (compliance, performance, accessibility, brand, legal).
- Invite Developer questions that reveal hidden complexity or cheaper options.
- Split oversized items when sizing shows they threaten a usable Done slice.
- Agree on examples or acceptance signals without turning acceptance into a personal QA gate that replaces the Definition of Done.
What clarification is not
- Handing Developers a closed design and forbidding technical alternatives
- Waiting until Sprint Review to reveal true expectations
- Using “I’ll know it when I see it” as a substitute for inspectable outcomes
- Expecting Developers to guess stakeholder politics without transparent ordering rationale
Unclear items produce false forecasts, thrashing mid-Sprint, and weak inspection—empiricism fails because nobody shared a transparent baseline of intent.
Negotiate Scope Within the Sprint Without Endangering the Sprint Goal
The Sprint Goal is the single objective for the Sprint—a commitment that creates cohesion and focus. The set of selected Product Backlog items and the plan can adapt as more is learned. The Guide’s model is protect the Goal when possible; adapt the plan and negotiate scope when reality changes.
Healthy mid-Sprint negotiation
When new information appears (technical surprise, market signal, dependency slip):
- Developers inspect progress toward the Sprint Goal and update the Sprint Backlog plan.
- Product Owner and Developers discuss whether selected items still best serve the Goal.
- Scope may be renegotiated—drop, swap, or split work—without abandoning the Sprint Goal if the Goal remains achievable and valuable.
- New opportunities that do not serve the current Goal typically go onto the Product Backlog for future ordering, not forced into the Sprint as silent add-ons.
| Allowed | Not allowed |
|---|---|
| PO and Developers renegotiate which PBIs best serve the Sprint Goal | PO unilaterally loads new work onto the Sprint Backlog as a personal task board |
| Reduce scope of a selected item to still meet the Goal with Done quality | Soften Definition of Done to “look finished” for a demo |
| Add a small clarifying piece if Developers agree it protects Goal value | Stakeholders inject work by bypassing the Product Owner |
| Cancel the Sprint if the Sprint Goal becomes obsolete (PO authority) | Keep a zombie Sprint when the Goal is dead just to “use capacity” |
Exam trap: Treating every mid-Sprint change as free. Capacity is finite. Negotiation is explicit trade-offs, not infinite scope under the same Goal.
Exam trap (opposite): Treating the Sprint as a fixed iron triangle of every selected story with zero adaptation. Scrum forecasts; it does not freeze learning for two weeks.
Developers Size; PO Influences Trade-Offs and Understanding
Developers size the work
The people who turn Product Backlog items into a Done Increment best understand effort, complexity, and risk. Developers size / estimate. The Scrum Guide does not mandate story points, hours, or any particular technique—only that planning is empirical and owned by those doing the work.
The Product Owner does not:
- Unilaterally declare “this is a 3; you will finish six this Sprint”
- Override team sizing with management pressure estimates
- Use estimates as a performance weapon against individuals
How the Product Owner still shapes decisions
Sizing is not isolation. The Product Owner influences trade-offs and understanding:
| PO lever | Example |
|---|---|
| Clarify value density | “If option A costs more but unlocks the Product Goal path, it may beat cheaper option B.” |
| Split for learning | “Let’s take a thin slice that validates the risky assumption first.” |
| Reorder by cost of delay | “Item Y is smaller but blocks a release; it may belong higher.” |
| Remove gold-plating intent | “We need outcome X; we do not need three themes of polish in this Increment.” |
| Expose constraints | “Regulatory logging is non-negotiable; include it in understanding, not as a surprise.” |
In Sprint Planning, the Product Owner brings ordered value and clarity; Developers decide how much they forecast they can complete to Done. Collaboration means joint discussion of options—not the PO forcing a forecast Developers do not believe.
Delegate Backlog Work; Keep Accountability
The Product Owner may delegate Product Backlog management activities—for example:
- Developers draft acceptance criteria or split items during refinement
- A domain expert helps detail a specialized PBI
- A designer elaborates interaction options the team will implement
Delegation improves quality and shared ownership. It does not transfer accountability. The Product Owner remains solely accountable for maximizing product value and for effective Product Backlog management (Product Goal, creating and communicating items, ordering, transparency).
| Pattern | Healthy? |
|---|---|
| Developers help write PBIs; PO reviews order and intent | Yes |
| PO asks a business analyst to facilitate stakeholder intake; PO still decides order | Yes |
| “Proxy PO” writes tickets while a VP holds real veto power and the named PO cannot decide | No |
| Committee votes backlog order while a figurehead “PO” takes meeting notes | No |
On the exam, if work is shared but a question asks who is accountable, the answer remains the Product Owner.
The Product Owner Does Not Tell Developers How to Build the Increment
This boundary is high-yield for PSPO I.
| Product Owner (WHAT / WHY) | Developers (HOW / WHO / WHEN of the work) |
|---|---|
| Product Goal and product value | Technical design and implementation approach |
| Product Backlog content and order | Sprint Backlog plan and task breakdown |
| Clarify PBI intent and business rules | Estimates, architecture choices, pairing, tools |
| Negotiate scope relative to Sprint Goal | Daily adaptation of the plan |
| Decide whether to release a Done Increment | Ensure work meets the Definition of Done |
The Product Owner may share preferences, constraints, and non-functional expectations that affect value (for example, “must work offline for field staff”). That is product intent, not a line-by-line work order. Crossing into daily task assignment, dictating code structure without value rationale, or running the Daily Scrum as a status report to the PO destroys self-management.
When Developers propose a different technical path that still meets the outcome and DoD, the Product Owner’s job is to understand impact on value, risk, and timing—not to enforce a preferred implementation for control’s sake.
Practical Collaboration Checklist (Exam Mental Model)
Use this when a scenario describes tension between PO and Developers:
- Is the Sprint Goal clear and still valuable? Protect it; negotiate scope around it.
- Are top PBIs understood? Clarify intent; refine or split before forcing a forecast.
- Who sized the work? Developers—not the PO alone.
- Who owns the Sprint plan and tasks? Developers—self-managing.
- Is DoD protected? No shipping undone work as Done to please a demo.
- Is the PO available without micromanaging? Clarification yes; task assignment no.
- If work was delegated, who is still accountable for value and the backlog? The Product Owner.
Scenario Drill
Scenario: Mid-Sprint, Developers discover that the top selected item requires a security review that will consume most remaining capacity. Stakeholders want two extra features added “while you are in there.” The Sprint Goal is “new customers can complete first-value setup without support.”
Sound collaboration:
- Developers surface the risk immediately and replan toward the Sprint Goal.
- Product Owner clarifies whether a thinner setup path still delivers the Goal and which acceptance outcomes matter most.
- Extra stakeholder features that do not serve the Goal go to the Product Backlog; they are not silently injected.
- Scope of the selected item may shrink; DoD is not sacrificed.
- If the Goal itself became obsolete, only the Product Owner could cancel the Sprint—here the Goal is still valid, so adapt within the Sprint.
That pattern—clarify, size honestly, protect the Goal, respect HOW ownership—is the PO–Developer collaboration standard PSPO I expects.
During a Sprint, Developers learn that one selected Product Backlog item is larger than expected. What is the best Product Owner collaboration pattern?
Who should primarily size Product Backlog items, and what is the Product Owner’s appropriate influence?
A Product Owner asks Developers to draft acceptance criteria for several Product Backlog items and later reviews the ordered backlog. Which statement is correct?