Keep the balance - Product Owner in Scrum

What role does a Product Owner have?
Scrum is counted as an iterative and incremental process used for product development and the organization of teams. The classical roles and structures are actually replaced by this procedure method through agile and transparent sequences. There result some new roles from this method. One of them is the role of the person responsible for a product, which is –in scrum jargon- called the Product Owner. This first part is about the Product Owners’ tasks, responsibilities and personal capabilities. A second article will appear in the next magazine regarding the role of the Scrum Master, which is also a new role resulting from this new procedure.
Scrum is based on simple rules, as is every other agile method, and for that very reason easy to understand. But still it requires a high amount of discipline at the same time.

It’s a struggle on two sides
One of those sides is the project team with its high self-motivation. In order to work fast and effective the team needs to organize itself; therefore it sets the tasks that need to be done and can be realistically done in a given amount of time. This given time is short and called a sprint. This responsibility leads to the self-motivation of the project team.
The most important thing for the success of scrum though is the role of the Product Owner, who serves as an interface between the team and other involved parties (stakeholders).
It can be said that in companies that use scrum, the tasks and responsibilities of the particular Product Owner are never the same. Starting with the choice of that person provided with the proper and necessary skills, make them take specific trainings, up to the responsibility they take; the role of the Product Owner –short PO- is the most complex one regarding that procedure.

Often the PO has to “fight” on both sides. Whereas the team can work a certain fraction of time (time boxed) “protected” by the Scrum Master, the Product Owner often needs to deal with marketing, management or the customers in order to be able to present the software requirements (User Stories) quite precisely to the team (see the box “criteria for User Stories).

Furthermore the Product Owner is responsible for the return on investment (ROI). He validates the solutions and verifies whether the quality is acceptable or not from the end-users’ point of view. He also has to decide over the importance of single features in order to prioritize these in their treatment and he has to tell the team what the product should look like in the end (product vision). Since one of the teams’ tasks is to work effectively, the Product Owner must react fast on call-backs. Hence he fulfils the role of a communicator, as he must be in contact with all stakeholders, sponsors and last but not least the team throughout a project. After all it is his task to coordinate the financial side of the product development, which is successful through his continuous work and prioritizing the advancing tasks (Product Backlog).
All these diverse requests demonstrate how important the selection of the “right” person for the role of the PO is for the success of a project.

Being a communication talent…
The Product Owner is not the only person who defines and gives requirements though. Often many stakeholders, as the marketing or guarantors of the quality assurance (QA) section are involved defining requirements on different levels. The company needs a better performance; the QA-section must assure certain safety standards and the marketing wants to build in the new corporate design as fast as possible. Due to that network the realization of the tiniest User Story takes up a lot of time and goes a long way through the entire company. The interests of all stakeholders may differ quite a lot, but they’ll always have one thing in common: their own requirements are the most important.
The task of the PO is on the one hand to assess the requirements and to keep the business value and also coordinate it and to decide when the team is realizing which requirements. On the other hand he needs to be provided with strong communicative, argumentative and diplomatic abilities. This is important for a two-way understanding between the responsible stakeholders and to create that way general acknowledgement.
The confidence of the involved parties, their participation and bidirectional flow of information lead to results, but also the problems can be recognized quickly and openly treated.

The Domain specialist
This is not even close to being everything. The Product Backlog does not only contain requirements but also the User Stories resulting from the requirements. Those User Stories need to be realized by the team. Besides the requirements elicitation and prioritization of the PO, he also has to be able to break down the requirements in concrete tasks. Therefore the PO needs a round about knowledge about what the product must perform in the end or rather to estimate what the user of the software is willing to pay eventually. A role like that does not exist in traditional corporate structures so far. For this very reason a controversial discussion about the occupation and the responsibilities of the PO always comes along with the introduction of agile methods as scrum. The question which classical role he should or could take in the company is not easy to answer. Depending on the corporate structure this could be the requirements analyst, the business analyst, the project leader, the product manager or others.
First we take a look at the classical project manager. With the adjustment to scrum he actually can only choose between the role of the Scrum Master (analog to the team- or project leader) and the Product Owner. Mostly the project manager chooses the Scrum Master because the Scrum Master is more likely to have tasks of a project manager and furthermore he works closer to the developing team. This decision is correct if he is primarily keeping the scum rules and being an aid for the team. That way he focuses on the “project lead”. The term agile leader describes to that effect the role of the Scrum Master the best (see “online sources”). In respect of analysis, regulation, budgeting and customer communication as required tasks, the classical project manager should more likely take the role of the Product Owner.

Scrum-ceremonies are checkpoints
Scrum knows three ceremonies. Two of those matter for the PO. During the “Sprint Planning meeting” the PO presents the most important requirements to the team and discusses those with its members. Before that meeting he already puts the requirements all together in the Product Backlog and prioritizes those. He has to answer all the questions of the team and he needs to point the direction – the “Big Picture” – and demonstrate the goals. That way the team can start the realization, already aiming at the asked goals.
In the end of that meeting the team commits to a particular number of prioritized requirements to be fulfilled until the end of that very sprint. The team clarifies together with the PO, which criteria the software has to meet in order to get bought. Now the team can start with the sprint, whereas the PO now has time to collect the following requirements and arrange them prioritized for the next Sprint Planning Meeting.

At the daily gatherings of the team – the Daily Stand Up Meetings or Daily Scrums –all stakeholders can participate including the PO; although they are not allowed to speak. This meeting only serves its purpose for the team and the Scrum Master because they talk about finished tasks, new tasks or problems that occurred.
The Product Owner acts in the end of the sprint at the Review Meeting again. The team presents the finished tasks to the PO and he checks whether the acceptance criteria are met or whether some rework is necessary.

Not everyone is a superman
Being a talent in communication, domain specialist, request-engineer and business analyst –a good Product Owner should be all of that. What can be done in a company where no-one has all of these abilities or when the product development is so complex that various teams work for one common goal?
One decisive reason for the success of scrum is the direct and clear communication between the particular roles. The team “promises” a person, namely the Product Owner, that it will fulfil certain tasks until the end of the sprint. If more than just one person acts as the PO the commitment would get lost.
A solution for that dilemma is the Product Owner Team which unites different skills and combines different activities. The members of that team identify the requirements, govern the budget, write User Stories ect. The Product Owner himself collects all information and is the responsible contact person for the team. That way know-how and capabilities of various people can be combined without disregarding the important “face-to-face” aspect of Scrum.

Since all companies have different structures, methods as scrum need to be adjusted. This does not mean that scrum needs to be changed but rather that the important rules get integrated in the context of a company.

Conclusion

The role of the Product Owner is complex and often difficult due to his voluminous duties and his requested diplomatic capabilities. He has to arrange the differing desires of all stakeholders by importance and he has to make sure everybody in the company accepts this list of prioritizations.

Furthermore many companies regard scrum only as a “software development subject” and aren’t aware of the consequences of the introduction of scrum. Producing a product - let it be software, hardware or a combination of both - requires the collaboration of all participants; starting with the idea and the finding of a functionality spectrum over to the realization and shipment and also desired changes and with that, new requests. All participants in that process should also participate in scrum.

Scrum is an effective and transparent method for the optimization of collaboration of all product-developing-participants. The Product Owner serves as an interface. This is what turns his “job” into an interesting and difficult one at the exact same time.

Marion Eickmann
Belongs to the founders of agile42 GmbH. The company specialized on consulting, training and coaching of agile processes as scrum.

About agile42:

We consider agile42 an agile company in more ways than one. We offer practice-oriented process consulting, training, coaching and software with a focus on lean and agile approaches like Scrum. The efficient combination of management involvement, knowledge transfer, team coaching on the job and a practice based tool support is responsible for our success in many international companies. After our projects, all Our customers testify that they achieved:

- Faster revenue generation
- Accelerated ROI (Return on Investment)
- Improved quality
- Quicker go-to market
- and last but not least increased motivation in all involved teams

agile42 GmbH
Marion Eickmann
Grünberger Str. 54
10245 Berlin, Germany

press@agile42.com
www.agile42.com

This release was published on openPR.