Scrum Roles
In Scrum, there are three roles: Product Owner, Team, and Scrum Master. Together these are known as the Scrum Team.
The Product Owner is responsible for maximizing return on investment (ROI) by identifying product features, translating these into a prioritized list, deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list. The Product Owner has profit and loss responsibility for the product, assuming it is a commercial product. In the case of an internal application, the Product Owner is not responsible for ROI in the sense of a commercial product (that will generate revenue), but they are still responsible for maximizing ROI in the sense of choosing – each Sprint – the highest-value items. In practice, ‘value’ is a fuzzy term and prioritization may be influenced by the desire to satisfy key customers, alignment with strategic objectives, attacking risks, improving, and other factors. In some cases, the Product Owner and the customer are the same person; this is common for internal applications. In others, the customer might be millions of people with a variety of needs, in which case the Product Owner role is similar to the Product Manager or Product Marketing Manager position in many product organizations. However, the Product Owner is somewhat different than a traditional Product Manager because they actively and regularly interact with the Team, prioritize by working with all of the stakeholders and reviewing the results each Sprint, rather than delegating development decisions to a project manager. It is important to note that in Scrum there is one and only one person who serves as – and has the final authority of – Product Owner, and he or she is responsible for the value of the work; though that person doesn’t have to work alone.
The Team (officially called Development Team) builds the product that the Product Owner indicates: the application or website, for example. The Team in Scrum is “cross-functional” – it includes all the expertise necessary to deliver the potentially shippable product each Sprint – and it is “self-organizing” (self-managing), with a very high degree of autonomy and accountability. The Team decides how many items (from the set offered by the Product Owner) to build in a Sprint, and how best to accomplish that goal .
Each member of the Team is just a team member. Notice there are no fixed specialist titles in a group that adopts Scrum; there is no business analyst, no DBA, no architect, no team lead, no interaction/UX designer, no programmer. They work together during each Sprint in whatever way is appropriate to achieve the goal they have set for themselves.
Since there are only team members, the Team is not only cross-functional but also demonstrates multi-learning: each person certainly has special strengths, but also continues to learn other specialties. Each person will have primary, secondary and even tertiary skills, and is meant to “go to where the work is”; individuals take on tasks in less familiar areas to help complete an item. For example, a person whose primary skill is interaction design could have a secondary skill in automated testing; someone with primary skill in technical writing might also help with analysis and programming.
The Team in Scrum is seven plus or minus two people, and for a software product the Team might include people with skills in analysis, development, testing, interface design, database design, architecture, documentation, and so on. The Team develops the product and provides ideas to the Product Owner about how to make the product great. In Scrum the Teams are most productive and effective if all members are 100 percent dedicated to the work for one product during the Sprint; the Team avoids multi-tasking across multiple products or projects, to avoid the costly drain of divided attentions and context-switching. Stable teams are associated with higher productivity, so avoid changing Team members. Product groups with many people are organized into multiple Teams, each focused on different features for the product, with close coordination of their efforts. Since one team often does all the work (planning, analysis, programming, and testing) for a complete customer-centric feature, Teams are also known as feature teams.
The Scrum Master helps the product group learn and apply Scrum to achieve business value. The Scrum Master does whatever is in their power to help the Team, Product Owner and organization be successful. The Scrum Master is not the manager of the Team members, nor are they a project manager, team lead, or team representative. Instead, the Scrum Master serves the Team; he or she helps to remove impediments, protects the Team from outside interference, and helps the Team to adopt modern development practices. He or she educates, coaches and guides the Product Owner, Team and the rest of the organization in the skillful use of Scrum. The Scrum Master is a coach and teacher. The Scrum Master makes sure everyone (including the Product Owner, and those in management) understands the principles and practices of Scrum, and they help lead the organization through the often difficult change required to achieve success with agile development. Since Scrum makes visible many impediments and threats to the Team’s and Product Owner’s effectiveness, it is important to have an engaged Scrum Master working energetically to help resolve those issues, or the Team or Product Owner will find it difficult to succeed. There should be a dedicated full-time Scrum Master, although a smaller Team might have a team member play this role (carrying a lighter load of regular work when they do so). Great Scrum Masters can come from any background or discipline: Engineering, Design, Testing, Product Management, Project Management, or Quality Management.
The Scrum Master and the Product Owner cannot be the same individual as their focus is so different and combining them often leads to confusion and conflict. One common unfortunate result of combining these roles is a micro-managing Product Owner which is opposite to self-managing teams that Scrum requires. Unlike a traditional manager, the Scrum Master does not tell people what to do or assign tasks – they facilitate the process, supporting the Team as it organizes and manages itself. If the Scrum Master was previously in a position managing the Team, they will need to significantly change their mindset and style of interaction for the Team to be successful with Scrum.
Note: there is no role of project manager in Scrum at all. This is because none is needed; the traditional responsibilities of a project manager have been divided up and reassigned among the three Scrum roles, and mostly to the Team and Product Owner, rather than to the Scrum Master. Practicing Scrum with the addition of a project manager indicates a fundamental misunderstanding of Scrum, and typically results in conflicting responsibilities, unclear authority, and sub-optimal results. Sometimes an (ex-)project manager can step into the role of Scrum Master, but the success of this approach is heavily dependent on the individual, and how well they understand the fundamental difference between the two roles, both in the day-to-day responsibilities and in the mindset required to be successful. A good way to understand thoroughly the role of the Scrum Master, and start to develop the core skills needed for success, is to attend the Scrum Alliance’s Certified Scrum Master training.
In addition to these three roles, there are other stakeholders who contribute to the success of the product, including managers, customers and end-users. Some stakeholders such as functional managers (for example, an engineering manager) may find their role, while still valuable, changes when adopting Scrum. For example:
- they support the Team by respecting the rules and spirit of Scrum
- they help remove impediments that the Team and Product Owner identify
- they make their expertise and experience available
In Scrum, these individuals replace the time they previously spent playing the role of “nanny” (assigning tasks, getting status reports, and other forms of micromanagement) with time as “guru” and “servant” of the Team (mentoring, coaching, helping remove obstacles, helping problem-solve, providing creative input, and guiding the skills development of Team members). In this shift, managers may need to change their management style; for example, using Socratic questioning to help the Team discover the solution to a problem, rather than simply deciding a solution and assigning it to the Team.