Defining a criteria for product owners

 

Scrum has a role called Product Owner. This is basically the individual from the client team who represents them. She is the custodian of the vision and in charge of prioritising the backlog.

When introducing this role to the client, I see a lot of teams just blurt out this definition and ask the client to nominate who the PO (Product Owner) will be.

With no further guidance, the client team usually ends up selecting the biggest boss. This almost always does not end well.

In this entry, we will be looking at the criteria for selecting a PO for the project.

Are they committed?

There is a world of difference between complying and commitment.

Asked in the middle of a meeting by my boss:

    So Chencha will you be able to work on this role that has been suggested?

What do you think am likely to reply with?

    Yes I can.

No one wants to seem like they are not being a team player.

Yet when things get tough as they always do, compliance will just not cut it. The PO needs to strongly identify with the vision, to understand not just what is being built but why.

If they lack commitment, eventually the lack of energy will show and drag the team morale down. After all who wants to work on a project where the client cancelled the demo meeting the last three times.

Do they understand their business?

If you ask a child what his dad who is an Engineer does, his response at 5 years of age will be Engineer. This will be the same answer at 10 years and 20 years. Yet each time he means something different, he gains a better understanding of what his dad does as he grows.

The truth is even with strong commitment, if the PO is not competent, then she is not worth much to the scrum team.

The PO needs deep knowledge and experience from their field. The kind of knowledge that comes from being deeply immersed in their domain for years. This experience can then be translated to insights that the scrum team can use in building their products.

Can they communicate?

Good communication is typically understood as articulating your views.

Acting as the client, the PO may then interpret her role as one of issuing commands

A good PO must be able to balance advocating her views and inquiring on the views of the scrum team. She Should be able to communicate assumptions their business is making and how they inform the decisions that she is making now.

In case of differences between the client and development team, she is best positioned to mediate and bring the teams to a common ground.

Can they decide?

A good decision maker is both competent and courageous.

The PO must be able to understand options on a more granular level, as the sum of their characteristics rather than as distinct and indivisible items. For example, if there is a requirement to build in multithreading into the system, the PO should be able to see it not only as a faster vs slower application but also how this impacts their various users, the benchmark their competitors are using and resources available to the system once in production.

Decisions that don’t pan out well can be very painful experiences. Yet decisions must be made, the PO then must be courageous enough to take on the decisions without unnecessary delay.

What criteria do you use to select POs for your teams? Talk to me in the comment section below or on my twitter @ jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Published by

jchencha

API Engineer