Scrum Roles

Product Owner
The Product Owner role is responsible for defining and prioritizing the product and release backlog. This includes setting the relative priorities of stories, explaining the intent and acceptance criteria of stories, and determining if the implementation of a story is acceptable. The Product Owner should have a strong voice in quick tactical decisions that need to be made during a sprint such as which stories to drop or add; how to slice a story in order to get it done, or whether or not a customer issue or cross-team dependency should supersede scheduled new development.

The Product Owner role can be very difficult to implement because it must balance the needs of the Scrum Team with the needs of the Customer Team. Negotiating solutions acceptable to the Customer and aligned with the technology and architecture constraints can be challenging. Balancing new features against the Scrum Team’s need to keep the product healthy through refactoring and addressing technical debt can also drive conflict.

Balancing between the Scrum Team and Customer Team is further complicated by the differences in language and communication that each of these teams uses. The Product Owner is frequently asked to translate the needs and information across this boundary. An effective Product Owner is versed in both languages and has the respect from both teams.

In Scrum, there should be a single Product Owner in order to assure a single voice in decision and prioritization. The Product Owner role can be shared by members of the product team and in some cases the Business Analysts have often had some of the Product Owner responsibilities delegated to them. This may cause some confusion with respect to which role owns which product decisions. Efforts should be made to identify the product owner roles and responsibilities when this role needs to be shared.

Scrum Master
The Scrum Master is responsible for facilitating the Scrum process. This involves:
  • Facilitating the Scrum meetings including the Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective meeting.
  • Creating and maintaining the artifacts needed by the team and the organization to manage the process.
  • Making sure that all the team members understand their roles and fulfill them to the best of their ability. This may sometimes involve coaching or training. In particular, when new members join a team, the Scrum Master would normally be explain the process to the new member and help that person learn how to fulfill their role.
  • Facilitate the resolution to all identified impediments. There may be some impediments that the Scrum Master cannot directly remove. Such impediments may have to be escalated, or temporary workarounds may have to be put in place in prior to the final resolutions.
  • Facilitating cross-team communication.
The Scrum Master role is best represented as a Servant Leader. This means that the Scrum Master supports the team, because it is the team which actually produces the goods. The Scrum Master should not overly direct the team, but rather guide/coach/mentor the team to take on the responsibilities of the process and the ownership of the product. This can be difficult at times depending on the team’s maturity level and may require more direction initially to bring the team forward. With more mature teams, the Scrum Master role can be embedded in all of the team members. The goal for a Scrum Master is to lead their team to this self-organization state.

Sprint Team Member
Team members are responsible for doing the work towards delivering working software that satisfies the stories that the team has committed to doing each sprint. This work may involve writing documents, writing tests, executing tests, or setting up environments, as well as designing and writing code. Team members are responsible for actively participating in all team activities, including:
  • Participate in release planning through assisting with the decomposition of user stories, estimating user stories in story points.
  • Tasking out stories in Sprint Planning meetings, including estimating the hours on those tasks and asking the product owner the clarifying questions required to understand stories well enough to task them out.
  • Participating in Daily Scrum meetings and working out dependencies between team members.
  • Assisting the team to reach its sprint and release goals which may include performing tasks that are outside their area of expertise.
  • Participating and demonstrating working software in the Sprint Review and listening for feedback from the Product Owner and other stakeholders.
  • Constructively reflecting on the process in the Sprint Retrospective through identifying areas in the process that are working well, identifying items that the team should improve upon and taking action on those improvement areas identified.
Stakeholders
Stakeholders have investment in the product being developed, but are not directly related to the development of the product. Stakeholders make up the Customer Team that provides input into the product backlog. Stakeholders may include Customer Support, Sales, Marketing, Corporate Executives and other managers, Enterprise Architects, etc. Stakeholders are encouraged to attend the Sprint Review and provide feedback to the Scrum Team on the product developed in that sprint and the future direction of the product.


   Foxkeh