Is being a Product Owner a Full Time Job?
By: Luis Carlos Arias Leiva
Tags: Agile, Agile Methodology, Product Owner, Scrum, Agile Coaching

Have you ever been part of an agile team full of rockstars who can commit to a ton of work per sprint and still you notice that something is not totally right? Maybe, you see lots of development but no concrete results?

As you may already know, a Product Owner is one of the many key pieces that makes an Agile team run smoothly. This person is the one that provides that heart beat to the team and feeds our backlog with all sorts of requirements for new work and improvement ideas.

But, why is it so hard to find a dedicated PO that can keep up to the task of providing a backlog that keeps a team busy sprint after sprint?

There are several answers to that..

PO positions at agile teams are generally filled with business representatives who have sufficient experience in a specific area of interest. (Those famous Subject Matter Experts)

This doesn’t always mean that this person is fully knowledgeable of how an agile process works. When teams are formed is usual to see very strict filters to get good Developers, Scrum Master, QA’s and other specialists. But, what about PO’s?

Well, the answer usually is..

- We found a guy who knows a lot about the business process but he’s never been a PO.. Oh! And BTW, he has many other things to do.

Another answer may be..

- We found a person that knows a bit about Agile, however, she is new to the company and doesn’t understand the business process very well.. Oh! And BTW, she’ll be PO for more than one team at the time.

Now let’s take a step back and analyze why is the PO position a full time job.

Prioritizing and building a backlog that suffices the necessity of keeping a team (sometimes an oversized one) busy through several sprints and keeping it as tidy and logically ordered as possible it’s sometimes an astronomical and almost impossible to reach goal for some PO’s. It requires hours and hours of stakeholder management, business insight and an incredible talent for documenting in a fast, concise and easy to understand style.

On a high profile Agile team, work items (often called User Stories) are usually taken as literally as they get written by the Product Owner, these work units must be fully groomed (once or twice) prior bringing them into sprint planning and hopefully written in an easy to read and hard to get lost methodology (i.e. Behavioral Driven Development). This implies that there’s always room for business rules and functionality gaps between User Stories, if individual features are not documented in a way that these gaps get covered the team will start noticing that something is missing in between. This can cause multiple setbacks (including tech debt increase) which will increment uncertainty and lack of confidence on what is being delivered as a quality product that will last.

But that’s only the first part! A PO job involves a holistic view of the picture; it is not only defining the path to follow but it also means to be on top of what’s being done and reacting fast to team discoveries along the way. If you are a Product Owner remember that this is your product (no need to say that the role’s name is self explanatory) and you are responsible for what the team is doing and how the team spends their time; at the end of the day everything gets translated to $$$. It is also necessary to say that priority changes are always welcome in Agile, however, these changes have to make sense and be cohesive with business goals.

That being said, I will call out some signals that may help you identify if your Product Owner is having trouble:

User story acceptance issues. Poorly documented US acceptance criteria causes confusion, misunderstandings and time waste.

Poorly documented US acceptance criteria causes confusion, misunderstandings and time waste. No logical order of priorities. Team might get blocked by non-existent context or architecture to develop on top of what’s needed. Tech debt increases.

Team might get blocked by non-existent context or architecture to develop on top of what’s needed. Tech debt increases. Not enough backlog. Time management related — Team member usage can stall and resources are wasted

Time management related — Team member usage can stall and resources are wasted Lack of business acumen. Knowledge gaps cause misdirection of efforts and overhead when issues need to be fixed.

Knowledge gaps cause misdirection of efforts and overhead when issues need to be fixed. Constant priority shifts. Agile welcomes changes, however these are accepted to a certain extent, common sense needs to be put to work.

Agile welcomes changes, however these are accepted to a certain extent, common sense needs to be put to work. Team frustration. Teams members are the perfect thermometer when finding out that something is wrong. Ridiculous priority shifts, direction issues and lack of work items can frustrate a team.

Teams members are the perfect thermometer when finding out that something is wrong. Ridiculous priority shifts, direction issues and lack of work items can frustrate a team. Increased tech debt. Frequently caused by last minute requirements which increase overhead and affect team’s velocity

Frequently caused by last minute requirements which increase overhead and affect team’s velocity Team image issues. Value delivery delays/errors can change how a team is perceived by upper management, these are not always provoked by the team itself.

As a final thought, a Product Owner role is not to be taken lightly. Our job is to make it visible in our organizations, these people are in charge of sailing the boat and in their hands is the responsibility of assuring that final customers needs are fulfilled at their maximum. Let’s give this role the importance it deserves.

— Luis Carlos Arias