What Are The Roles In A Scrum Team?
What is a Scrum Team?
What are the roles within a Scrum Team?
What are the responsibilities of each role within Scrum?
There are three roles in a Scrum project. They are the Scrum Master, the Product Owner, and the Development Team. No other roles are allowed within the team. It is possible for one person to be assigned to more than one role but this is not recommended. While Scrum outlines, in detail, how a Scrum team should behave, it does not prescribe how an organisation should behave. It is most beneficial that the organisation the Scrum Team is a part of or the customer the Scrum Team is working for have a good understanding of Agile and Scrum. A Scrum Team is self-organising and cross-functional. A self-organising Scrum Team assigns and is responsible for the delivery of the work. In addition, a Scrum Team does not have an external manager directing their actions. A cross-functional Scrum Team has all the technical capabilities within the team to complete the project. Self-organising and cross-functionality allows a Scrum Team to be flexible, creative, and productive.
The role of a Scrum Master could be a full-time or part-time role depending on the organisation and project. One person could hold one or more roles in a Scrum Team, however, this is not advised. A Scrum Master may also work on more than one project at a time. A Scrum Master is responsible for ensuring Scrum processes are implemented correctly and to coach other Scrum Team members. They are responsible for delivering the highest value to the business utilizing the Scrum processes. The Scrum Master is a servant-leader role and is responsible for managing the Scrum process as opposed to the Scrum Team. The Scrum Master does not have any direct reports. They typically manage through influence and negotiation. One of the main roles of a Scrum Master is to remove any roadblocks a Scrum Team may encounter while also facilitating Scrum Events. A Scrum Master assists an organisation to train, understand, and adopt Scrum.
The Scrum Master is focused specifically on the Scrum Process. The Product Owner is specifically focused on the content within the Scrum process. The Scrum Master assists the Product Owner by making sure that all stakeholders are aware of and understand the projects scope and goals. The Scrum Master assists by clarifying the need for concise Stories, using effective Product Backlog management techniques, assists with maximizing value through the Product Backlog, and facilitating Scrum Events if needed. The Scrum Master assists the Development Team by working with them to create high value products, coaching them in Scrum methodologies, assisting with optimising self-organising and cross-functionality, and facilitating Scrum Events when required. The Scrum Master assists the organisation by coaching the organisation and assisting it with the adoption of Scrum. They also assist with the planning and implementation of Scrum. Finally, they assist with changes that increase the productivity and effectiveness of the Scrum Team within the organisation.
The ultimate responsibility of the Product Owner is to maximise the business value of the product and the Development Team. Delivering the highest values product/feature allows an organisation to gather feedback and move through the build-measure-learn cycle much faster. An organisation is also able to realise their ROI much sooner. Customers and users are the most important stakeholders to Product Owners. There is only ever one Product Owner per Scrum Team however one Product Owner may work on multiple projects simultaneously. In addition, while not ideal, the Product Owner may have more than one role in a Scrum Team. The Product Owner is responsible for the Product Backlog. No one else within an organisation should touch the Product Backlog unless the Product Owner has delegated responsibility to them. But, ultimately, the Product Owner is 100% accountable for the Product Backlog. A committee or organisation can provide input and feedback to the Product Owner, but the committee cannot hold the role of Product Owner. Product Owners do not need to be technical experts with regards to the output of the project. They simply need to have an understanding of what is being delivered and how the business operates.
There is only one Product Backlog per product and will remain as long as the product exists. The Product Backlog is the main planning tool for the project and helps define its scope while focusing the Scrum Team on the project goals and mission. The Product Backlog represents all the requirements of the product including features, functions, requirements, enhancements, and fixed. Each item in the Product Backlog is called a Story. A Story holds information about what the client would like developed by the Scrum Team. Each Story withing the Product Backlog should have a description, order, value and estimate (D.O.V.E.). The Product Backlog is prioritized with Stories at the top providing the greatest value to the business. Stories lower down the Product Backlog usually have less detail. The Product Owner is responsible for collecting information for the Stories. The Product Owner and Development Team work together to make sure the Stories have the right amount of detail. This process is called “refinement” and should take up no more than 10% of the Scrum Team’s time.
Below is a picture of the Product Backlog for useinfluence.io. On the left you can see different coloured icons representing different types of User Stories. The green represent a normal User Story. Red is a technical issue or bug. The orange is a question that needs to be answered. The blue relates to to marketing. On the right you can see the Epics and person the User Story is assigned to.
Product Owners are also responsible for measuring the performance of the Scrum Team, forecasting, and making this information available to all stakeholders. No one within the organisation can tell the Product Owner how to value the Stories in the Product Backlog. However, stakeholders can provide input and insight to make ordering the Stories easier and more accurate. The Product Backlog and the Scrum Backlog are the only places the Development Team work from. The Product Owner is the main contact between the organisation/customer and the Development Team. The role of the Product Owner is to gather information from the organisation and provide enough detail to the Development Team so they are able to build the product with as little interruptions and task switching as possible.
It is mandatory for the Product Owner to assign value to each Story in the Product Backlog but Scrum does not define how that value is to be attributed. Time, cost, risk, coherence, policies, and input for the Development Team should all be considered. The Product Owner is responsible for updating all stakeholders in the Sprint Review. It is mandatory for the Product Owner to attend all Scrum events except the Daily Scrum. Only the Product Owner has the authority to cancel a Sprint and does so if the work no longer suits the project. If done, all Stories in the Sprint Backlog that have not been completed are returned to the Product Backlog. All Stories that have been “done” are reviewed and released if appropriate.
In a Development Team there may be a front-end developer, back-end developer, tester, architect, Business Analyst and designer. While all of these roles are different, Scrum does not recognise titles other than the Development Team. Ideally, there should be between three and nine members of a Development Team. There are no sub-teams within a Scrum Team. The Development Team are responsible for the delivering of the Stories that have been moved from the Product Backlog into the Scrum Backlog. Two key characteristics of the Development Team is that they are self-organising and cross-functional. With these two characteristics, the Development Team organise and distribute their own work throughout while making sure that the whole team is responsible for all the work. Each member of the team has a “T” shaped capability meaning they have a broad understanding of everything within the team (represented by the horizontal part of the “T”) and they have deep technical knowledge in one particular area (represented by the vertical part of the “T”). This structure is essential in for working in an adaptive framework as it empowers the team to self-govern, make decisions and continue delivering as opposed to escalating to management and waiting for a decision which has the potential to slow the team down.
The structure or people in the team should rarely change. If change is needed, it should not be done during a Sprint, but rather, at the beginning of the next Sprint. The Development Team members should, ideally, be assigned to one Scrum Team so they can focus on one project at a time to reduce inefficiency and switching costs. The Development Team should be focused on delivering working software at the end of every Sprint. This software is added to the Increment and planned for release. Only members of the Development Team create the Increment. They should be constantly aligned with the Sprint’s scope and goal.
Below you can see an image of my Jira instance. During the Sprint Planning meeting, the Scrum team would discuss what should be built next and how it should be built. The User Stories would be moved from the Product Backlog, to the Sprint Planning and then to the Current Sprint after the Scrum team has agreed on the work to be completed within that Sprint.
The roles above are, strictly, part of the Scrum Team. The roles below are not part of the Scrum Team but are closely related and work closely with the Scrum Team.
The Business Owner role provides important information and direction to the Scrum Team but is not a part of Scrum. The Business Owner is responsible for setting the vision and mission of the product. The vision answers the question “why does this product exist?” The visions helps create a shared understanding and alignment within the team. The vision also helps keep the Scrum team track their progress and eliminate any unnecessary items from the Product Backlog.
Subject Matter Expert
A Subject Matter Expert (SME) is not part of the Scrum Team. When necessary, the Scrum Team may call on expertise from outside the Scrum Team to assist in clarifying information or providing guidance. SMEs can be invited to Scrum meetings but do not participate in the Daily or Sprint Retrospectives.
The role of Project Manager does not exist in Scrum. The project management responsibilities have been distributed throughout the Scrum Team. That does not mean to say that project management has been removed from Agile or Scrum. It simply means it has been coordinated in a different way.
As always, if you have any questions, feel free to reach out or comment below.