Can A Scrum Project Have Multiple Product Owners Or Scrum Masters?

By Author: Mrugesh panchal
Total Articles: 48
Comment this article

Can there be multiple scrum masters for multiple teams within scrum?
Scrum has simple but straightforward rules regarding the team composition. For every scrum project, ideally there should be only one product owner, only one scrum master, and one development team. In certain cases, when development is to be carried out on a very large scale and the product has to be delivered within a shorter time frame, the management can opt for multiple development teams. However, in such cases, each team has its own specific and individual functioning, and maintains its own burn down charts and estimation patterns. There can be a discussion pertaining the role of the scrum master when multiple teams are employed, and multiple sprints are planned simultaneously. Generally, the scrum master should be available for the sprint team, and be accessible when required. If multiple teams function simultaneously, how feasible would it be for one scrum master to cater to all? Scrum advocates that the scrum master be primarily responsible for enforcing and implementing scrum in an effective way at ...
... all times during the tenure of the project. For this to happen, the scrum master is required to be physically present with the team while it is working. It may not be possible for one scrum master to coordinate multiple teams simultaneously. During such special or extra ordinary circumstances, the management may opt for an additional scrum master to look after the other team. Therefore, in theory, and in practice, there can be multiple scrum masters in a single scrum project.

Can more than one product owner handle a scrum project?
If more than one scrum master can be allotted in a scrum project, what about multiple product owners? Is this possible? The answer to this question is highly debatable. The product owner is a very important entity in scrum, and owns the project on behalf of the stakeholders. To fulfill his or her responsibilities, and play the role of the product owner in an effective manner, the person is also vested with certain authority. To debate the question, if multiple product owners are recommended for a project, how is the overall authority of the project to be delegated? How can more than one person carry out activities generally conducted by a single product owner?

• Creating and grooming the product backlog
The product owner designs and writes the product backlog items, and thus creates the product backlog after the release planning. The PO is also responsible for determining the priority of the user stories based upon the business values of the epics. In addition, the PO and the team members also carry out the grooming activity jointly. If multiple product owners are allotted, which of the product owner decides about allotting story points to user stories for estimation purposes? Individuals tend to differ when activities are to be carried out using their own judgment or prior experience. What may be acceptable to one, may not be recommended by the other. It would create more confusion and lead to difference of opinions while deciding the priority of scrum related items, and the team may experience a loss or ownership since it remains uncertain as to which product owner should be ideally approached when acceptance criteria is to be clarified or updated.

• Approving the user stories during the sprint review meeting
One of the foremost and most important activities of the product owner is to approve the user stories developed during the daily sprints. The process may sound simple since the acceptance criteria is clearly stated in the backlog items, and all the team has to do is follow the instructions regarding how a particular story ought to be ideally developed. In reality, things are not as simple as that. As is the case, in most instances the team feels it has carried out the development activity in a proper manner, in accordance to what has been stated in the acceptance criteria. However, the team may have failed to fulfill a certain benchmark essential to make the story shippable. Perhaps the main reason why this happens is the development team has a different perception while developing the user stories during the sprints, and the product owner assumes a very different perspective regarding what completed user stories should ideally contain. The viewpoint is fundamentally different. The product owner looks at user stories as potential business entities which can make the product successful in the market. The development team, on the other hand, focuses whether the user story is technically sound i.e. whether it functions properly at the time of testing the functionality. The team does not concentrate upon up to what extent the story is useful to the end user, but rather concentrates whether the story is functional. For the product owner it is the other way around. If multiple product owners are to engage in the scrum project, it may further complicate how the developed items should be accepted as “done” and approved for demonstration to the stakeholders during the sprint retrospective meeting.

A special case – disjointed or remote development teams and product owners
With the advent of outsourcing on the rise, the management may be forced to keep remote teams operating from different geographic locations. In such scenarios, the management may appoint a dedicated project owner who can remain physically present, and function as a dedicated product owner for the remote team. The primary reason why this is allowed is because the remote team may need immediate answers to real life problems, and the time difference between countries may not make it feasible for a single product owner to serve two teams, with each team operating in accordance to its local time and schedule. Different product owners are appointed so the daily sprints do not suffer, and it remains physically and practically possible to get successful product increments in a sustained manner.