Every member of the Scrum Team plays the role of Team Member, but only one Team Member is held accountable to the Business for the Scrum Team’s success and the value of the Scrum Team’s results. That’s the Product Owner or PO, for short. And that accountability is a big thing – it defines the PO as the formal leader of the team as far as the outside world is concerned.

The PO is the Scrum Team’s eyes and ears to the outside world (the Stakeholders). They are the Scrum Team’s one point of formal contact, the conduit of information. Add to this that the PO has the Scrum Team’s back. Meaning, in being held accountable for the Scrum Team’s results, the PO is consumed with making sure the Scrum Team is getting the proper feedback to make the right Product at the right pace. The PO spends a lot of time scoping the product, clarifying murky expectations, negotiating delivery dates, and making it all fit for the Scrum Team.

We should also note that even though the word ‘Owner’ is in the title, the PO may not be the Product expert. Granted, the PO has a lot of knowledge and skills, but the role is defined by accountability, not by product-specific skills. A good PO realizes there may be a wealth of smarts both inside and outside the Scrum Team and knows how to leverage this for both the Scrum Team’s good and the product’s good.

While the PO is the eyes and ears toward the outside world, the ScrumMaster’s eyes and ears are pointed decidedly inward in many ways. The ScrumMaster (SM) is an informal leader worried about what’s going on internally within the Scrum Team and making sure that Scrum is being used correctly.

The ScrumMaster is a leader without managerial responsibilities as part facilitator, part influencer, and part guru. They are laser-focused on the health of the Scrum Team and the Scrum Team’s continuous improvement, especially when it comes to the Scrum Team’s use of Scrum. The ScrumMaster does this by helping improve the Scrum Team behaviors and working relationships, removing stumbling blocks (in Scrum Speak called ‘impediments’), and dealing with constraints.

Many people new to Scrum quickly understand getting to know their ScrumMaster is essential to feeling grounded and productive. Because the ScrumMaster is inward-looking, and the Product Owner is outward-facing, it is inappropriate for the same Team Member to play both the Product Owner and ScrumMaster roles.

The term “Development Team” represents the portion of the Scrum Team that is currently developing or creating the product – and this may, or may not, include the PO and SM. It is proper and often useful for the PO and SM to be on the Development Team, but they must always realize that their leadership roles come first.

You can think of the Development Team a little like the Three Musketeers, operating by the motto, “All for one and one for all.” When Scrum is really working well, and Teams are performing at a high level, the Development Team acts in the Development Team’s best interest, with everyone doing their part to achieve a collective goal. Each member is held responsible for the Development Team’s Product Production.

Unlike many work Teams, Development Teams function on a level playing field. There are no specialized roles. It’s as straightforward as it sounds; every Team Member is just that, a Team Member. Development Teams tend to be small, ideally around five people. However, at times a project may dictate a slightly larger group. Every Team Member shares the same primary goal of partnering with the other team. Members to deliver the right product to the best of their abilities. Every Team Member is invested in the same secondary goal to help avoid spinning its wheels and improve as a self-organizing, cross-functional group.

• Business Owner The three most critical external roles are a sort of triumvirate of Scrum. The external roles of Business Owner (BO), Stakeholder, and Subject Matter Expert (SME) maintain an important level of influence in the Scrum process through the PO. The BO also works with the PO to weigh in on the priority of future work in the Backlog, assist in altering the Release Plan if needed and help the PO better understand the needs of the Stakeholders. On an organizational level, the BO works closely with the ScrumMaster to help alleviate organizational impediments that get in the way of the Scrum Team’s success.
• Stakeholder We can think about a Stakeholder as anyone who is invested in the project or the product. To this point, there are two types of Stakeholders: internal and external. Every Team member is an Internal Stakeholder but, for the sake of today’s journey, we will focus our attention on the external Stakeholders, a.k.a. “The Big Kahunas.”
  
  If it weren’t for the external Stakeholders, there wouldn’t be a Scrum Team producing a Product. There will always be many people interested in the Scrum Team’s Product; however, it’s only the Stakeholders who truly have a vested interest in the product. It’s important for the Scrum Team to recognize the Scrum “food chain” here and give the Stakeholders their props. It’s essential for the team to try their hardest to satisfy the Stakeholders’ needs and work with the PO and ScrumMaster when things get in the way of realizing these needs.
• Subject Matter Expert(s) As we’ve noted above, Scrum Teams are cross-functional groups who are knowledgeable about many things, but there may be times when the Scrum Team doesn’t know everything about everything it needs to know. And that’s why Scrum utilizes Subject Matter Experts (SMEs). SMEs bring something unique to the team that it doesn’t possess on their own. Perhaps it’s technical knowledge, business knowledge, database expertise, or a host of other things that are needed to make the right Product the right way.
  
  A SME is a consultant in every ounce of the word. He or she imparts know-how to the Scrum Team and walks away. No accountability or responsibility. With that comes a bit of risk. Despite the SME being chock full of critical expertise, he or she does not share the Scrum Team’s priorities and goals. Scrum Teams should follow some sage advice when using SMEs: try to treat them as part of your team, but remember and respect that they may have priorities that pull them in a different direction.