A Scrum team needs one (and only one) Product Owner

Recently, I presented some of my conclusions after attending (again) the Professional Scrum Product Owner training. As I wrote, the Product Owner’s role remains the vaguest in the Scrum Guide, because it is very dependent on the company in which he evolves. It reads: “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”

However, the Product Owner’s role is essential and mandatory to succeed in implementing the Scrum framework. The Product Owner is the one who instills vision, gives direction and changes course as needed. It’s a complex role and the person who have to assume it needs to be trained and supported.

The PO believes in his product and is best placed to define what is valuable and what is a priority. Of course, a savvy Product Owner will rely on the insights of customers, stakeholders, and team members, but he or she will have the final say in prioritizing their Product Backlog.

No Product Owner

Let’s first say that when there is no Product Owner in a Scrum team … then it is not a Scrum team! In such a situation, the development team tries to do the best they can and it sometimes causes changes within the team.

• The Substitute Developer

It often happens that a member of the development team becomes Product Owner. In principle, it is the developer with the most advanced functional knowledge. He takes on this role as best he can, but he sails visually and is seldom confident in his choices.

The biggest problem is the developer’s legitimacy with stakeholders and also with his fellow developers. Although there is no hierarchical relationship between the Product Owner and the development team, the definition of the PO’s role makes it clear that he has the final say in prioritization. What about when he is a developer showing goodwill but who has not been inducted?

A Product Owner will access market research, compare what the competition is doing and gather feedback from colleagues and customers. How do you think these people will react if a stranger comes to ask them questions? How can a developer instill in the team a vision of the product?
In addition, by experience, a PO/developer favours its developer’s hat when there are delays or stress to deliver features. Thus leaving his role as PO, the whole team is greatly impacted.

• The Substitute Manager

Sometimes a supervisor takes the role of Product Owner. While this can be done in good faith to try to help the development team move forward as best as possible, the hierarchical relationship will conflict with the team’s self-organization. The dialogue will be distorted and the team may have difficulty defending themselves, particularly regarding the content of the sprints. Retrospectives can also have a different hue with a manager in the room.

• No PO at all

When nobody takes the role of Product Owner, it can even turn into total chaos. Each of the team members will have their opinion on the functionality that must be developed as a priority, the vision will be clearly non-existent and cohesion may be difficult to achieve. As developers are naturally more familiar with technical aspects, development choices and prioritization may be more oriented towards these than functional considerations.

Without an official Product Owner, we find that teams run out of steam after a few weeks without a clear direction and having the feeling of not providing as much value as possible, while being little recognized. If the company decides not to free up time for someone to play the PO’s role, does that mean that the solution that is being developed is ultimately not so high a priority? In any case, it is the impression the team could have. Fatigue will also come from the loss of time thus created. Each validation and each choice requires more time, discussion or even negotiation.

One Product Owner and half a team

In some businesses, a PO is actually assigned to the product, but the product team is not set and has to take care of many other projects/maintenance tasks. Recurring problems are then encountered.

The prioritization is not carried out by a single person, there is, on the one hand, a flow managed by a PO and on the other, IT and maintenance requests. Who is able to prioritize between request X and request Y? The developer often finds himself doing the arbitration alone, without really knowing if it is the company’s strategy. In this situation, is it possible to ensure that what is most valuable is actually being developed?

Even with all the goodwill in the world, the Product Owner’s sprint goals can rarely be achieved because it’s hard to know at the start of the sprint how long the team will really be available for the product. The negotiation with the Product Owner that should take place in the context of any Scrum project is biased, because it is impossible for him to have an opinion on products that do not concern him.

Finally, let’s not forget the loss of time related to lack of concentration and constant task switching…

One “Duct” Product Owner and one team

The Product Owner I call “Duct” is often a person who has been dropped in this position, but who does not have the necessary knowledge or “power” to fulfill the role.

For example, it could be a person who has vague knowledge of the product and has just arrived in the company. In this situation, a “duct effect” will occur because the Product Owner will never be able to formally answer questions and will always need to request validation elsewhere. The answers will generally be of this type: “Yes, I think that’s it, but wait, I will validate with X or Y.”

This situation may be acceptable if we know that the Product Owner will be there in the long run, that he is building skills and knowledge. As time goes by, he should be able to assert himself more and more and acquire the necessary knowledge. Conversely, if it is someone who’s not engaged, who does not have the time necessary to build skills, who occupies the role transiently on the short term, it will generate, as in other situations, slowness, frustration and maybe an increment of little value at the end of each sprint.

Two Product Owners

Remember that the Product Owner’s work is complex, demanding and often requires 100% of his time. That is why it can be tempting to designate two Product Owners rather than just one in order to spread the workload. I will immediately cut to the chase: it is not a good idea! And it’s not Scrum…

Again, in such a context we face problems of prioritization and vision. Product Owner A will prioritize one way and Product Owner B another way: who should you listen to? While one must be open to change, the loss of time brought about by turnarounds and decision changes is not beneficial to anyone.

In parallel, when two Product Owners are assigned to the same product, but are sharing responsibility for different areas, a question can sometimes arise: could it not be two different products? If so, it might be good to have a dedicated team for each product.

On the other hand, the Product Owner may be helped by other people, business analysts, for example. It is not a team of Product Owners, the Product Owner remains responsible for the backlog and its prioritization. An analyst may help collect users’ needs and write user stories. In this case, the Product Owner has to be careful not to always question the information provided by the analyst.

The perfect match: One Product Owner and a dedicated product team

Do we still need to clarify further? Only by having members with clear roles can a Scrum team really be effective. By a clear role we mean:

• An engaged, visionary and committed Product Owner aware and clear with his priorities.He can be helped by other people in defining and writing user stories as long as he remains in control of his product and is sufficiently involved with the team
• A Scrum Master
• A multidisciplinary development team

These conditions are a good start to declare: “We are using Scrum” but it is still necessary for the Scrum team to be organized around a product…