Scrum Accountabilities in Practice: Product Owner, Scrum Master, Developers

Three Accountabilities, One Team Outcome

Scrum defines three accountabilities: Product Owner, Scrum Master, and Developers. They are not job titles; they describe who is accountable for specific outcomes. In practice, you will collaborate with all three every sprint. The goal is to make decisions quickly, keep work aligned to value, and deliver a usable Increment.

Product Owner in Practice

Responsibilities during a sprint

• Keep the Sprint Goal and desired outcomes clear as new information emerges.
• Clarify Product Backlog Items (PBIs) so Developers can build the right thing.
• Make trade-offs when scope, time, risk, or quality constraints collide.
• Review progress toward value and adjust ordering of upcoming work (without disrupting the Sprint Goal).
• Accept work based on agreed quality criteria and the Definition of Done (DoD) and any additional acceptance criteria for a PBI.

Decision rights (what the Product Owner decides)

• Ordering of the Product Backlog (what is most valuable next).
• What “value” means for the product in the current context (often informed by stakeholders and evidence).
• Release intent and what is ready to be released (in collaboration with the organization).
• Scope negotiation when the team needs to adjust to still meet the Sprint Goal.

The Product Owner does not decide how Developers implement the work or how tasks are assigned.

Typical daily behaviors you will observe

• Answers questions quickly or schedules short clarification sessions.
• Reframes requests into outcomes (e.g., “What user problem are we solving?”).
• Checks that work aligns with the Sprint Goal and product direction.
• Validates assumptions with stakeholders and brings feedback back to the team.

How a new team member should interact with the Product Owner

When you need clarification, aim for outcome-focused questions and propose options. Keep it lightweight and time-boxed.

Step-by-step: asking for clarification on a PBI

1. Restate the intent: “I understand the goal is to reduce checkout abandonment for mobile users.”
2. Point to the specific uncertainty: “I’m unsure whether we should support guest checkout in this sprint or only improve the error messaging.”
3. Offer options and impacts: “Option A is faster but less complete; Option B takes longer and may risk the Sprint Goal.”
4. Ask for a decision: “Which option best supports the Sprint Goal?”
5. Confirm acceptance expectations: “What would make you confident this is done and valuable?”

Example script

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

PO, I want to confirm the outcome for PBI-142. Is success defined as fewer failed payments, faster checkout, or both? If we can only do one this sprint, which matters more for the Sprint Goal?

Boundaries and anti-patterns (Product Owner)

• Anti-pattern: Product Owner as sole requirements writer. If the Product Owner writes everything alone and hands it off, Developers lose shared understanding and discovery slows down.
• Anti-pattern: “PO approves every task”. Acceptance is about the Increment/PBI meeting agreed criteria, not micromanaging implementation steps.
• Boundary: Product Owner does not assign work. Developers decide how to accomplish the Sprint Goal.
• Boundary: Product Owner should not change the Sprint Goal casually. If reality changes, renegotiate scope with Developers; don’t churn priorities daily.

Scrum Master in Practice

Responsibilities during a sprint

• Enable effective Scrum events (facilitate when helpful; teach the team to self-manage).
• Remove impediments that slow progress or reduce quality.
• Coach collaboration and help resolve conflicts constructively.
• Protect focus by helping the team handle interruptions and unplanned work transparently.
• Improve the system: work with the organization on policies, dependencies, tooling, and cross-team coordination.

Decision rights (what the Scrum Master decides)

• How to coach and facilitate Scrum practices to improve effectiveness.
• How to escalate impediments and who to involve to remove them.
• Which improvement experiments to propose (the team decides what to adopt).

The Scrum Master does not decide scope, ordering of the Product Backlog, or assign tasks.

Typical daily behaviors you will observe

• Asks questions that reveal blockers and assumptions.
• Helps the team keep work visible (e.g., board hygiene, WIP awareness).
• Facilitates quick alignment when the team is stuck.
• Works outside the team to remove systemic impediments (access, approvals, environment issues).

How a new team member should interact with the Scrum Master

Use the Scrum Master as your first stop for process questions, team collaboration issues, and impediments you cannot remove yourself.

Step-by-step: raising an impediment

1. Name the impediment clearly: what is blocked and since when.
2. State the impact: risk to Sprint Goal, quality, or delivery.
3. Share what you tried: actions already taken to unblock.
4. Ask for help with a specific next step: escalation, access, decision, coordination.
5. Agree on ownership and follow-up: who does what by when.

Example script

Scrum Master, I'm blocked on integrating the payment service because I don't have access to the staging secrets. I requested access yesterday and followed up today. This blocks PBI-142 and risks the Sprint Goal. Can you help escalate to the platform team or suggest an alternative path?

Boundaries and anti-patterns (Scrum Master)

• Anti-pattern: Scrum Master as project manager. Tracking individuals, assigning tasks, and enforcing deadlines undermines self-management and shifts focus from outcomes to compliance.
• Anti-pattern: Scrum Master as meeting scheduler only. The Scrum Master’s value is improving flow and removing impediments, not just running ceremonies.
• Boundary: Scrum Master does not “own delivery”. Developers own creating the Increment; the Scrum Master enables effectiveness.
• Boundary: Scrum Master should not shield the team from all reality. Transparency matters; the team should see constraints and participate in solving them.

Developers in Practice

Responsibilities during a sprint

• Create a Done Increment that meets the Definition of Done.
• Plan the work needed to achieve the Sprint Goal and adjust the plan daily.
• Collaborate across skills (design, coding, testing, documentation, security, data, etc.) to complete PBIs.
• Maintain quality through practices like reviews, automated tests, continuous integration, and refactoring.
• Make progress visible and surface risks early.

Decision rights (what Developers decide)

• How to build: architecture, technical approach, engineering practices.
• How to split work: tasks, pairing/mobbing, sequencing.
• How to manage WIP to maintain flow and quality.
• What is feasible within the sprint while meeting the Definition of Done.

Developers do not decide Product Backlog ordering; they do influence it by sharing effort, risk, and learning.

Typical daily behaviors you will observe

• Work in small slices that can reach Done quickly.
• Swarm on the most important item when needed.
• Review each other’s work and integrate frequently.
• Proactively clarify acceptance expectations before building too much.

How a new team member should interact with Developers

As a new team member, your fastest path to contribution is to make work visible, ask early, and pair on a real item.

Step-by-step: joining work without creating disruption

1. Pick a Sprint Goal-aligned item and ask who is closest to it.
2. Ask for the current understanding: “What’s the smallest Done slice we can finish next?”
3. Offer a concrete contribution: write a test, update documentation, implement a small component, validate an edge case.
4. Confirm DoD expectations before coding heavily (tests, reviews, security checks, etc.).
5. Integrate early and request feedback quickly.

Boundaries and anti-patterns (Developers)

• Anti-pattern: Developers working in isolation. Long-lived branches, late integration, and “my ticket” thinking increase risk and reduce learning.
• Anti-pattern: Throwing work over the wall (dev to QA, dev to ops). The team is accountable for Done, not partial completion.
• Anti-pattern: Treating acceptance criteria as optional. If expectations are unclear, clarify; don’t guess and hope.
• Boundary: Developers should not accept unplanned work silently. Make it transparent and renegotiate with the Product Owner if it threatens the Sprint Goal.

Good Collaboration: Practical Micro-Patterns

Micro-pattern: clarify before you build

• Trigger: You notice multiple interpretations of a PBI.
• Action: Ask the Product Owner for the outcome and a decision between options.
• Result: Less rework; clearer acceptance.

Micro-pattern: raise risks early with options

• Trigger: You discover a dependency or technical risk.
• Action: Tell Developers first, then bring the risk and options to the Product Owner (scope trade-off) and Scrum Master (impediment removal) as needed.
• Result: Faster decision-making; Sprint Goal protected.

Micro-pattern: keep feedback loops short

• Trigger: Work is taking longer than expected.
• Action: Slice smaller, integrate sooner, demo partial progress to the Product Owner for direction.
• Result: Better alignment and fewer surprises.

Role-Interaction Map for Common Scenarios

Quick Reference: What to Do When You’re New

• If you’re unsure what “good” looks like: ask Developers about the Definition of Done and team engineering practices; ask the Product Owner about the outcome and acceptance expectations.
• If you’re blocked: try one self-service step, then raise it to the Scrum Master with impact and evidence.
• If you get a direct request from outside the team: acknowledge, capture details, and route to the Product Owner for ordering; keep Developers informed.
• If you notice hidden work: make it visible to Developers; if it threatens focus, involve the Scrum Master and Product Owner to renegotiate.