Normally, when we hear about Scrum we only hear talking about the development team or about the Scrum Master. What about the Product Owner? Why don’t we talk about him, about all his hard work?
As a Scrum Master, I must say that the Product Owner does not have an easy life. There are many difficulties he faces every day.
For example, to understand what the customer needs, what the customer wants and what is economically feasible to do, is a huge task. We may be talking about the company’s internal customers, external customers or customers that represent a specific market. In each case there has to be a different approach.
Internal customers tend to be more demanding and less patients. The contact is often personal, which can also be a good thing. Communication is essential and a good PO has to establish a way to communicate with his customers that ensures he understands the customer’s needs.
In my opinion, the personal contact is the ideal way. Unfortunately, we can’t always do it that way. But most of the time people prefer to communicate via email or a chat of any kind. This form of asynchronous communication is slow, may create misunderstandings and the result is not satisfactory. A PO can create itself difficulties if he can’t find an effective way to communicate with his customers.
When a Scrum team develops an application that will be used for a specific market, with whom the PO has just a few contacts, the PO faces new difficulties. How to please everyone? What is truly a priority? How to receive feedback?
But this is nothing compared to what’s coming.
Then we have the User Stories. It seems a simple task to write one, but it’s not.
As a Product Owner I would like to write a User Story simple and clear so that the team develop it more easily.
In fact, you need a lot of expertise to write a set of User Stories that leave no doubt, don’t depend on each other and are small enough to contain something to add to the product.
Sometimes the Dev team looks into two User Stories and thinks it would be much more productive to develop the two simultaneously, since it will force to modify the same piece of code. Or it would be better to test the two at the end, after they are both coded because the second US may interfere with the first scenario.
It’s a huge and understandable temptation. The real problem is in the way the User Stories were written that didn’t took into account how a developer codes.
So far we realized that a PO has to be a good Communicator and have some knowledge about the art of coding.
But he will have to be a good negotiator too.
One of the most important tasks of a PO is to set priorities on the product backlog. It is essential for the team to have a prioritized backlog.
Depending on the kind of project, this can be more or less complicated. The PO may work on a project with others POs where each is responsible for a portion. In this case he will have to coordinate priorities with others POs.
If he works with internal customers he needs to be a strong negotiator because each customer will only recognizes its own priorities. In these cases the PO will have to deeply develop his negotiating skills.
In any case, the definition of priorities is the result of a set of requirements of third parties, which the PO will have to understand and bring to the team’s product backlog.
The team starts working on the project.
Since the team starts to study the User Stories till finishing its development, the PO has no rest. Thousands of questions are raised that have to be clarified, new requirements that have to be considered and even technical problems, that put into question a User Story, and that have to be overcome.
The PO’s availability is a must.
In summary, a good Product Owner must have a set of skills that are fundamental to facilitate his work and wins the confidence of the team.
In addition to knowing the product and its market, he needs to be a good Communicator, a good Negotiator, understand the art of coding and always be available for the team.
Are you prepared to be a Product Owner?