From Scrum Roles to Accountabilities—What’s the Difference?

We used to talk about the “roles” in Scrum, but since the 2020 Scrum Guide, the word “accountabilities” has been introduced. So what’s the difference and has the emphasis changed? Let’s take a closer look.

The Scrum Guide is a living document, and based on feedback from users of Scrum, the changes were to iterate and come up with a better, simpler description(s).The overall theme of the 2020 Scrum Guide was to simplify the Scrum framework—to make it less prescriptive and to simplify the “rules” of Scrum. 

Roles in Scrum

Previously, the Development Team, Scrum Master, and Product Owner had responsibilities, which a lot of us translated into roles. The problem was that these roles were not clear at saying these were accountabilities of the three roles. But despite not using the word “accountabilities,” the Development Team, Scrum Master, and Product Owner always had things within the Scrum Team and the Scrum framework that they were accountable for ensuring took place during a Sprint. The Scrum Master, Product Owner, and Development Team, are accountable for specific areas which requires specific skillsets. At the same time, they need to collaborate together to deliver maximum value each Sprint.

Accountabilities in Scrum

With the 2020 Scrum Guide changes, there is now an emphasis on the accountabilities—Scrum Master, Product Owner, and Developers. And the Scrum Guide lists out the specific responsibility each one has. This makes it clear and more direct as to who is accountable for things within Scrum. For example, the Product Owner is accountable for the team delivering value and accountable for the success of a project. Developers are accountable for delivering a quality, useable condition product every sprint. And the Scrum Master is accountable for the effectiveness of Scrum being used by the team and within the organization.

Developers Versus Development Team

One last thought: The team “Development Team” was changed to “Developers.” This change was made for a couple of reasons. The idea of having a second team within a Scrum team was confusing. The term “Developers” is more universal and is not referring to software development. The Scrum Guide is trying to simplify the language and make it more inclusive of a wide range of areas that use Scrum for their work that isn’t necessarily technical. We have Scrum everywhere, from CrossFit gyms to HR Departments to education systems.