Scrum Roles and Accountabilities

In the last unit you saw Scrum as a transparency engine. That engine has three operators, and confusion about who operates what is one of the quietest ways a team stalls. This unit gets the accountabilities sharp enough that you can protect them the moment they blur, and grow the team's ability to hold them without you.

Scrum defines exactly three accountabilities, and they are accountabilities, not job descriptions. The Product Owner is accountable for value and ordering: the what and the why of the product. The Developers are accountable for the Increment: the how, including how the work gets built and who picks up which piece.

The Scrum Master (you) is accountable for the team's effectiveness and the process: helping everyone use Scrum well. A clean field test cuts through most disputes. If a decision is about what to build or in what order, it belongs to the Product Owner. If it's about how to build it, it belongs to the Developers. If it's about how the team works together, it's yours. So when someone tries to hand you a decision that isn't yours, name the real owner and hand it back: "That's a value and ordering call, so the Product Owner needs to weigh in. Let's bring it to them." You're not dodging; you're keeping the line visible.

Those lines hold fine on a calm day and blur under delivery pressure. The most frequent collision: a Product Owner reaches past the "what" into the "how," handing specific tasks to specific developers because directing people feels faster. Your move is not to quote the rulebook. It's to honor the intent behind the behavior, usually predictable delivery, while restoring self-management.

This is where servant-leadership versus command-and-control earns its keep. Command-and-control says the leader decides and assigns. Servant-leadership says you create the conditions for the team to decide well and clear what's in their way. Your authority comes from the process, not from directing the work.

• Jessica: I've already mapped out who does what this Sprint, it'll just move faster if I assign it.
• Ryan: I hear the intent, you want predictable delivery. Help me protect that. Which outcomes matter most this Sprint?
• Jessica: The notifications work has to land, and the export fix.
• Ryan: That's yours to set, and you just set it clearly. Now let the Developers decide who takes which piece. They'll flag it in the Daily if anything threatens those two outcomes.
• Jessica: So I still get the visibility, I'm just not handing out tickets.
• Ryan: Right. You own the goal; they own the plan to reach it.

Notice Ryan never said "that's not your job." He split the what (hers) from the how (theirs) and showed her she keeps the thing she actually wanted.

The most common dysfunction lands on you. The Scrum Master slides into project manager: assigning tasks, chasing status, owning the board alone. It feels helpful, and the team happily lets it happen, but it quietly kills self-management. The corrective is concrete behavior swaps. Instead of updating the board, ask the team to update their own. Instead of chasing status, make impediments visible and let their owners act. The other dysfunctions mirror this shape, a Product Owner managing the how, Developers waiting to be told what to do, and each one is a boundary crossed plus a capability that never gets built.

Maturity is how you build that capability back, deliberately rather than by sudden declaration. You hand off facilitation and decisions in sequence, easiest first: a developer runs the Daily Scrum, then the team owns one impediment end to end, then they facilitate a Retrospective. You step back as they step up, and you watch for the signs maturity is growing: the team unblocks itself, decisions happen without you in the room, and nothing goes quiet when you're away.

The one idea to carry: each accountability owns a different question, what-and-why, how, and how-we-work, and your job is to protect those lines without policing them while the team learns to hold them itself. Next, you'll put that judgment to a quick test, sorting a stack of real decisions and activities to the accountability that owns each. Try saying the owner out loud before you check the answer.