When working on a Scrum project the success depends on the effective fulfillment of the role of Product Owner (PO). The Product Owner is typically the person in Scrum who is appointed by the Client to represent the project. 

At the beginning of each product development, the client is the most knowledgeable about the concept.

During the project, developers might acquire more in-depth knowledge on specific parts they are working on, but it is always the client who maintains a global knowledge of the whole product. Additionally, the client always has a much better understanding of the industry and field for which the application is developed.

To be a good Product Owner is not as simple as it might seem. Especially when the project is the client’s first project delivered in Scrum, we can’t expect that the Client will serve as an effective Product Owner without prior experience.

Therefore at the beginning of the project we must mutually allocate enough time and resources for the appointed PO to get to know his / her tasks and to acclimate into the role.

In the following posts we are going to summarize the typical tasks of a Product Owner and how to perform them effectively.

We are not going to go into details about the Scrum methodology, we are only focusing on the PO tasks and responsibilities.

1. Planning and prioritizing

The Product Owner’s task is to determine in each sprint (short iteration of development) what features to be developed and even more importantly, what are the priorities of those features.

The Product Owner must participate at every sprint planning/review meeting and should be (even if virtually) present on every daily standup. He / She must be able to answer all non-technical questions that might come from developers. Sometimes a simple question during a daily standup (like “exactly what conditions must be met for a visitor to be able to push this button?”) can identify blind spots or reveal mutual misunderstandings. 

The Product Owner represents the Client, but is not necessarily the decision maker from the Client side. 

When the PO is not authorized to make a decision alone then his / her duty is to go through the decision making process of the company and have all issues decided by the start of the upcoming sprint planning. This includes adding new features, providing design, changing existing features or reprioritizing the Backlog. The Backlog is a Scrum term which refers to the list of all features to be developed during the project. The PO will select tasks for each sprint from this list, according to the Backlog item priority.

The Product Owner must know exactly what he wants, how he wants it and in what order.

At the sprint planning meeting the PO presents each feature to the development team and answers their questions. It is advisable for developers to ask as many questions as possible and rephrase how they understood the features with their own words.

This might seem cumbersome at first, but this is exactly what is needed to recognize the illusion of mutual understanding. Correcting a misunderstanding during planning is cheaper by orders of magnitude than rewriting finished code because of a later realization that it is not what the Client meant. Any PO who has experienced such a scenario before will understand and appreciate the value of mutual understanding and thorough planning.

It is also important that the planning meeting should not turn into a brainstorming session. Conceptual questions about features should already be answered and decided. The question should always be how to develop and not what to develop. Usually we spend a half day for review-planning, including accepting completed features and planning the next sprint. 

However, if any conceptual gaps or undecided questions emerge during the planning meeting that the PO can not answer right away, the meeting will last far longer than originally planned. This  is problematic as the whole team is present for the planning meeting, so developers end up doing the job of planning-brainstorming instead of coding which is a very inefficient use of resources. 

The Product Owner should do pre-planning before each sprint planning. The developers can be involved in this process to give technical feedback to the PO about the feasibility and expected costs of planned features. Naturally this cannot be considered a through estimation, more like a draft estimate that will help the PO to consider including the feature into the product backlog or look for different solutions.

In the next post we are going to discuss the PO's role in writing specification and user stories.