Scrum Roles Defined
I do a lot of work with Scrum Teams and the ones that struggle the most are the ones where the Scrum roles are defined poorly and\or not filled properly. Scrum is a balanced framework and when the roles get muddled, the framework begins to adopt the dysfunctions of the organization and is not as powerful as it could be.
In Scrum there are three roles – Team member, Product Owner and ScrumMaster. Those three working together are called the Scrum Team (or just the Team). I add a fourth role – Stakeholder – to recognize all the people who orbit a Scrum Team and influence them. I define all these roles like this:
- Team: dedicated collection of self-organizing, interdependent, co-located individuals representing different functional roles with all the necessary skills to turn Product Backlog items into a potentially shippable increment within the Sprint.
- Product Owner: an empowered individual applying their personal and professional judgment to make decisions in the best interest of different,often times competing, business stakeholders to maximize the business value the Team produces each Sprint
- ScrumMaster: a dedicated individual responsible for improving the performance of the Team and the business by any means necessary.
- Stakeholder: any person who has a direct, or indirect, interest in the work of the Team.
Keep in mind, these are role definition, not job descriptions and they are very loosely defined. It is important that each role is filled. In general, the Product Owner is concentrated on the providing valuable business outcomes to the business, while ScrumMaster is aiming his\her efforts at the execution of good Scrum and improving the flow of value to the customer. Meanwhile, the Team remains centered on learning how to self-organize and deliver potentially shippable increments regularly. Stakeholders provide feedback on the value of everyone’s efforts.
When Scrum falters, it is often because people are not committing to their roles. Other times, organizations chose to overload one, or more, roles in a single person, disrupting the balance of the roles. Recall, the Scrum framework was designed to provide the maximum amount of flexibility with the minimum amount of control. If these roles cannot be filled with individuals who will fully inhabit them, or they are overload, the control mechanisms of Scrum become unhinged, visibility is diminished, accountability is lost and the framework loses its meaning.
When Scrum is done well, there exists a natural tension between each role. This tension exerts a force that tends to prevent the other roles from meddling in responsibilities that are not their own. Since there are considerable gray areas on the role boundaries in Scrum, each role will eventually bump into one another as they discover what are the boundaries of their responsibilities. This friction is an essential part of learning how to do Scrum and making it meaningful to your business. Through the of process of inspect-and-adapt, the precise definition of each role – Team member, Product Owner, ScrumMaster and stakeholder – emerges as your organization gains experience using Scrum.
One of the main reasons why I add a Stakeholder role to Scrum is because many Scrum implementations improperly keep these people out of the process. Scrum was not designed to keep the Stakeholders from interacting with the Team. In fact, Scrum was designed to bring these folks closer together. What Scrum tries to do is give the Stakeholders a more meaningful, structured way to interact and provide the Team with feedback via the Sprint Review. This is the opportunity for the Team to hear direct, unvarnished feedback on what they really think. This is why Stakeholders have a dashed line connecting themselves with the Team, rather than a solid line.
I think you are messing up some terminology in your article and that might be dangerous for communication purposes.
The scrum team for example is not the combination of PO, SM and team but is the team itself.
Be sure to use the correct terms to avoid complicated situations.
You can see an overview of all roles in a schema I created on my bog.
For a good theory on all the roles, I find the website of scrum alliance a good recourse…
For the rest, keep up the good work… greetings!
Kenneth, thanks for the comment, your concerns and the link back to your blog.
You are correct that in Scrum each role is distinct and separate and there is a collection of people responsible for delivering the product at the end of each Sprint – IMO those people (Product Owner, ScrumMaster and the Team members) are called the Scrum Team. I wish Scrum had not overload the word “team”, but that is where we are.
What would you call the people responsible for delivering the product each Sprint?
I think, after diving a bit deeper into it, you where correct after all…
According to the Scrum Primer (http://www.goodagile.com/scrumprimer/scrumprimer.pdf) the combination of the 3 roles (SM, PO and team) is called the scrum team… A bit hard to distinguish all the roles…
I was explaining somebody Scrum yesterday and talked about all the roles, the chickens and the pigs, and she answered me this: Where those guys high when they came up with these names?
I guess she had a point… 🙂
Thx Carlton, sorry for the confusion and keep up the good work!