Accountabilities in the Scrum Framework

The 2020 version of the Scrum Guide has played a bit of a shell game with the Scrum roles. It doesn’t matter which cup you look under; the roles are gone.

Which of the Following Are Accountabilities in the Scrum Framework?

The 2020 Scrum Guide defines three accountabilities: Product Owner (maximizing value), Scrum Master (improving effectiveness), and Developers (creating increments). However, it’s worth noting that in the decade leading up to this, these accountabilities were referred to as roles—a significant shift.

Which of the following are accountabilities in the Scrum Framework?

1. Establishing Scrum as defined in the Scrum Guide.
2. Development Team.
3. Ordering Product Backlog items.
4. Coaching the team members.
5. Holding each other accountable as professionals.
6. Product Owner
7. Causing the removal of impediments.
8. Maximizing the value of the product.
9. Scrum Master
10. Creating a plan for the Sprint.
11. Creating any aspect of a usable Increment.
12. Creating Product Backlog Items.

Before diving into the 2020 Scrum Guide, I’d have confidently picked 1, 8, and 11 as the answers. It seemed apparent—those were the principal accountabilities for the classic Scrum roles. But here’s the twist: I would’ve been wrong. This change isn’t just semantics; it shifts how we think about responsibility in Scrum.

Scrum Role vs Accountability

Scrum no longer defines roles; it uses “accountabilities” to highlight the responsibilities of the Product Owner, Scrum Master, and Developers. This shift focuses on ownership and results, not just titles. However, this change has led to questions about practical implications.

I’ll admit, the switch from “roles” to “accountabilities” in Scrum left me feeling a bit skeptical. I’ve always found the term accountability to be fuzzy at best. So, let’s turn to the dictionary and see if there’s more to this than just a trendy word swap.

Merriam-Webster defines role as:

“a function or part performed especially in a particular operation or process.”

I can see the logic here. Scrum Master, Product Owner, Developers—they all have their pieces of the puzzle when delivering a product. Everyone’s got their part, and it all fits together to make sure things actually get done.

Merriam-Webster defines accountability as:

“the quality or state of being accountable” and adds, especially, “an obligation or willingness to accept responsibility or to account for one’s actions.”

If I tilt my head and squint a bit, I can kinda see the intent behind using “accountabilities.” It’s like they’re trying to bundle up a set of responsibilities with a dash of ownership—like, not just doing the work but owning it, and being ready to explain if things go sideways. Maybe that’s the angle they’re taking with the Scrum Master, Product Owner, and Developers. It’s a stretch, but I can almost see it.

My heartmate likes to remind me that admitting I’m wrong isn’t exactly my strong suit. So, as a recovering right-a-holic, I thought I’d see if it’s just me tripping over this terminology switch. And wouldn’t you know it? I’m not alone. A quick look at Google trends shows that “Scrum Master Role” still outshines “Scrum Master Accountability” by a mile. I guess I’m right again!

So, I can’t help but wonder, why did the authors of the Scrum Guide feel the need to mess with the terminology? If “roles” were working just fine, why the shift to “accountabilities”? It feels like change for change’s sake, doesn’t it?

Are There No Roles in Scrum?

Scrum no longer defines roles; they’ve been replaced by accountabilities to move away from rigid job descriptions that distract teams. This shift aims for a flexible, outcome-driven approach, but it’s more than semantics—some accountabilities are more impacted.

The Scrum Master accountability? Yeah, that one’s always in the hot seat. It’s misunderstood as glorified admin work, and don’t even get me started on those job postings calling it entry-level. Even the team’s often left wondering what the heck Scrum Masters do all day—assuming they’re not completely useless, that is.

Let’s talk about two kinds of Scrum Masters. You’ve got the one who thinks their whole gig is running meetings and jotting down notes—a glorified facilitator with a pen. They’re there, taking attendance, keeping time, and typing up every last word like it’s the gospel truth, thinking that’s the secret sauce to team efficiency. It’s not exactly wrong, but let’s not pretend it will revolutionize the way the team works.

Then there’s the Scrum Master who gets it—gets it. They know their accountability isn’t just playing secretary but coaching the team to become more deliberate, sharpen their focus, and own their processes. This Scrum Master doesn’t just hand out meeting notes; they teach the team how to capture what matters, cut through ambiguity, and turn a conversation into action. They’re not there to do the work for the team—they’re there to empower the team to do the work better and make them more efficient, not by taking notes but by teaching them the value of clarity and intentionality. It’s the difference between keeping a team in check and helping a team truly grow.

This seemingly subtle shift from asking “What’s my role?” to “What outcome am I supposed to be achieving?” can have a profound impact. It’s a mindset change that moves beyond just doing a job to truly understanding the value you’re bringing. And I believe this is precisely what the authors of the Scrum Guide were aiming for. They weren’t just redefining terms; they were pushing us to rethink how we approach our work and our accountability to the team.

Accountabilities in the Scrum Framework

In the Scrum Framework, accountabilities like Product Owner, Scrum Master, and Developers signify the outcomes team members should achieve, not fixed roles that require specific hires. Anyone capable can assume these accountabilities, making them flexible and adaptable—but that flexibility often leads to unanswered questions.

1. Is the Scrum Master a full-time job?
2. Can the same person be the Product Owner and Scrum Master?
3. Can a developer be a Scrum Master?
4. Should the dev manager be the Scrum Master?

All these questions pop up because overlapping accountabilities create a fog of confusion. When we thought of them as roles, it was easy—hire someone for each spot. But accountabilities? They’re like coats anyone can grab and throw on. And let’s be real, coats are great, but you can only wear so many before you’re weighed down and sweating bullets.

What is the answer to most of the questions above? That classic consulting line: “It depends.” But seriously, it does depend. Scrum isn’t about rules for the sake of having rules. It’s more like an engine built to let teams customize their ride. What works wonders for one team might be a total disaster for another. What could drown one team might lift another—Scrum’s all about finding your way, not following someone else’s playbook.

The Scrum Guide does not say that a single person can’t hold multiple accountabilities. So, if you’re looking for a straight answer to the questions above, you’re out of luck—it’s all about experimenting to see what fits or flops in your organization. There’s no one-size-fits-all, just your team’s journey to figuring it out.

A Scrum Team Has How Many Specific Accountabilities

A Scrum team has three accountabilities: Product Owner, Scrum Master, and Developers, each handling critical elements of the delivery process. The actual effectiveness comes from how these accountabilities balance, ensuring no single perspective outweighs the others.

Left unchecked, each accountability could veer off course. Developers would obsess over perfect code and the latest tech. Product Owners would push for a feature factory, cranking out functionality fast. Scrum Masters? They’d hog the team’s time, coaching every second away on process tweaks. The balance between them keeps the team on track, not chasing their own agendas.

The Scrum Guide lays down a system of checks and balances. The Product Owner can’t just stuff the Sprint with new features on a whim because the Developers create the Sprint Backlog. They decide what’s doable, keeping the PO’s ambition in check and ensuring the team isn’t overloaded with wishful thinking.

The Scrum Guide keeps the Scrum Master in check by ensuring they can’t dictate how the team works or take over with endless coaching. Developers run their own show, managing their work and deciding how to tackle the Sprint Backlog. Meanwhile, the Product Owner keeps everyone’s eyes on the prize—value delivery—so the Scrum Master doesn’t get too wrapped up in process over progress. The Scrum Master is there to serve, not steer, focusing on the team’s needs, not their agenda.

This balancing act is exactly why it’s tough for one person to juggle multiple accountabilities. Sure, you might find someone who can see things from two angles, but let’s be honest—it’s a rare find. What are the odds of one person fully embodying two perspectives without losing the plot? Slim to none.

TLDR

Roles have vanished in the 2020 Scrum Guide, replaced by accountabilities that drive outcomes over titles. But this isn’t just a vocabulary change—it’s a complex balancing act that makes it tricky for one person to juggle multiple perspectives without tipping the scales.

Works Consulted

• Google Trends Scrum Roles vs Accountability
• Accountabilities in Scrum: It’s A Complete Picture Now
• Agile Accountability: It’s Not What You Think
• Accountability, Responsibility and Roles
• What does a Scrum Master actually do all day?