Understanding How Responsibilities and Accountabilities Play Out with Scrum

Frustration, confusion, and tiring discussions result from unclear responsibilities and accountabilities.

How often do you stumble upon one of the following?

• That’s not my responsibility!
• I expected you to do it. You’re accountable for that.
• That’s your job, not mine.

I’ve been in such weird discussions more times than I can count. 

The more unclear responsibilities and accountabilities are, the more frequently you get trapped into such tiring arguments.

But then comes the question, what’s the difference between responsibilities and accountabilities? Answering this question is fundamental to Scrum teams. Failing to do that is a problem you don’t want to deal with.

Let me elaborate on the difference between these key terms and how that plays out with product teams. Hopefully, you’ll better understand how Scrum teams could benefit from clarity and function as stronger teams.

What’s the Difference Between Responsibilities and Accountabilities

It took me a while to understand the difference between these words. My native language is Portuguese, where responsibility and accountability have the same translation. I simply couldn’t understand what one was and what the other was. Don’t feel embarrassed if you don’t know that.

To explain it, let’s look at the dictionary:

Responsibility: the state or fact of having a duty to deal with something or of having control over someone.

Accountability: the state of being accountable, liable, or answerable.

I assume it’s still unclear to you. At least to me, it’s not precise enough.

Now, let me shed some light. Consider a restaurant. The Chef is accountable for the dishes’ quality and taste. That means when something goes wrong, the Chef is accountable, even when somebody else cooked. The cooks may be responsible for cooking, but they aren’t accountable for the result; the chef is. The Chef can delegate the cooking responsibility but remains accountable for the result. 

In summary, accountability is a heavier burden than responsibility.

Connecting to Scrum—we all know many teams are trapped in feature factories. They are responsible for delivering features defined by someone outside the team. Yet they aren’t accountable for the result created by these features.

How do accountability and responsibility play out with Scrum members? That’s the next question I’m going to elaborate on.

Product Owner 

The perception of accountability and responsibilities of all Scrum roles vary dramatically. I won’t go into that, but I’m about to describe what I believe to be an optimal way of splitting accountabilities and responsibilities.

Accountabilities

• Product Vision: Craft a Product Vision that points the team in a meaningful direction.
• Product Strategy: Define a strategy that enables the team to decide what to do and what not to do.
• Goals: Set meaningful goals that enable teams to focus and intensively collaborate towards a unique direction.
• Value Maximization: Prioritize meaningful problems that maximize the outcomes for users and businesses.
• Communication: Ensure stakeholders are well-informed about results, decisions, progress, etc. In summary, stakeholders should never say, “I was unaware of that.”  

Responsibilities

• Stakeholder Management: Engage with stakeholders to partner up and create value for products. This includes organizing meetings, workshops, communication, etc.
• Backlog Management: Curate, sort, and clean up the Product Backlog to ensure it contains the most relevant items to create value.
• Roadmap: Craft product roadmaps to provide perspective and set expectations on where the product is heading.
• Monitor results: Constantly evaluate KPIs to understand how the product creates value for end-users.
• Product Discovery: Ensure continuous learning to enable innovation and solve problems users care about. 

Let me give you an example: If a stakeholder says, “I didn’t know this feature is live,” the Product Owner may say, “Well, you missed our review. Your fault.” That’s a misunderstanding. The Product Owner is accountable for communication, which means everyone has to be on the same page.

I love taking thoughts from Jeff Patton to illustrate the accountability of Product Owners:

“We don’t need an accurate document. We need a shared understanding.”

Developer

A gray zone between Product Owners and Developers creates confusion and frustration. I’ll give you my understanding, which is based on my experience. You may have other perspectives, and I’d love to hear from you :)

Mind your step. You may step on someone’s toes and get them angry.

Accountabilities

• Quality: Ensure the code meets the agreed quality standards.
• Scalability: Create solutions that scale to the required business needs.
• Efficiency: Guarantee solutions are efficient from the users’ perspective.
• Maintainability: Develop an application that can be maintainable by other professionals.

Responsibilities

• Solution: Implement solutions that solve the agreed problems.
• Test: Perform required tests to meet the quality expectations.
• Delivery: Define a delivery process and execute it accordingly. 
• Estimate: Only those who work on the solution can estimate it.

Please, Software Engineers, don’t hate me. I know your job goes way beyond what I described. I’m just trying to clarify the differences between accountability and responsibility. You’re accountable for quality, which means if I find a bug in production, we’re going to talk.

However, if my dear Product fellows or I push you to deliver faster and encourage cutting corners, please, call us out. Here’s a suggestion:

“Trying to speed project schedule by reducing testing is like trying to lose weight by donating blood.” — Klaus Leopold

Scrum Master

I feel pity for many Scrum Masters. I know how hard it is, getting this job right. I played this role several times and I respect those who put their love and energy into it.

One of Scrum Masters’ biggest challenges is facing the misunderstandings of accountabilities and responsibilities. I must say some things before jumping to that.

Scrum Masters aren’t responsible for scheduling meetings for any other team member. Scrum Masters are accountable for establishing Scrum as defined in the Scrum Guide.

I’m sorry, but there’s no room for babysitting, being the team’s secretary, or any other pointless mutation. 

The job is way more demanding than that. Sorry, I had to vent because I’m done with teams mistreating Scrum Masters. 

Accountabilities

• Scrum Understanding: Ensure business stakeholders understand how to play the Scrum game. 
• Framework: Ensure that all Scrum events occur and that all artifacts are created as defined in the Scrum Guide.
• Atmosphere: Develop a collaborative atmosphere with a balance between learning and delivering.
• Teams’ Effectiveness: Enable the team to grow and become as effective as possible.
• Enable Self-management: Unleashes the team’s potential by helping them become self-managing.

Responsibilities

• Ensure the Sprint Retrospective takes place: The Scrum Master may facilitate the Sprint Retrospective, but the responsibility is ensuring that it happens. Another team member can run the show.
• Ensure Retrospectives End with Actions: After each Sprint, Scrum teams discuss how to get better as a team. Scrum Masters ensure the result of the session has clear agreed actions.
• Coach Stakeholders: Invest whatever is necessary to coach key business people to enable teams to thrive with Scrum.
• Scrum Events: Ensure the team respects the Scrum Events frequency and timeboxes them. 

“In any given moment we have two options: to step forward into growth or to step back into safety.” — Abraham Maslow.

Final Thoughts

Through this article, I didn’t aim to give you a complete overview of ALL accountabilities and responsibilities of each Scrum role. My goal was to provide an overview and help you understand the differences.

My point is simple: get together with your team and agree on who’s accountable for what and the responsibilities. This will make your life easier and avoid many future confusions.

I know how painful it is to leave this unspoken. Please, don’t ignore the importance of clarity. This is fundamental to pave the way to create value faster.

“My advice is to stop emphasizing the process frameworks and start focusing on the company culture and mindsets.” — Selena Delesie.

‍