Many say that the P.O. is the most difficult role in Scrum. Depending on where you are in your evolution with Scrum, you may have even agreed with that statement. A realization we’ve come to as a result of working with graduates and clients is that the Product Owner role really isn’t the most difficult role in Scrum. We believe it is the most misunderstood role in Scrum.
Many organizations do not understand Scrum means making changes. Physically alternating the way work is performed. The longer they have worked using project management or a “waterfall” approach, the muscle memory in their company is strong. And old habits die hard.
Misunderstanding #1: Lack of Authority.
If your organization has made a sweeping generalization such as “all Business Analysts are no Product Owners” the Product Owner role is being misunderstood. According to the official Scrum Guide the Product Owner has authority to make decisions. Those decisions are respected by everyone in the organization. Now if your organization really has also given the “formerly known as B.A.” that kind of authority – awesome! But chances are unlikely. What results is overturned decisions from the real authority, delays, wasted time, wasted money, lost in translation and other impediments that slow delivery of value to the customer. Which is what Scrum is all about.
Misunderstanding #2: The P.O. Must Know Everything.
If your organization has made up roles that do not exist in the Scrum. Such as proxy Product Owner, Technical Product Owner, Business Product Owner, Co-Product Owner. There is a reason there is only one role called Product Owner. To avoid confusion about who the Development Team is taking direction from. What happens when all of these “product owners” try to give conflicting, contradictory direction to the Development Team? You guessed it. More confusion, delay, wasted money, wasted time and no value to the customer. Product Owners do not have to know all of the answers. Effective P.O.s seek input. That’s right. Input. They take technical info, marketing info, customer info, product info, financial info in and make an informed decision. As a proactive, collaborative leader, they seek input before they make decisions. This Refinement activity is ongoing and happening at varying levels and times. The P.O. doesn’t have to do it all by themselves but someone assisting or someone giving the P.O. input doesn’t need a silly, made up Scrummy title.
Misunderstanding #3: Refinement is a P.O. Meeting with the Developers.
If your Developers are stuck in full day “refinement meetings” with a Product Owner, it may be a sign that the P.O. doesn’t understand Refinement as an ongoing, proactive activity. P.O.s bring items for further refinement to the Developers when ready. That means an effective P.O. has already received input from stakeholders, customers, subject matter experts and made decisions. That doesn’t mean that further refinement won’t take place once the Developers gets involved, it means we’re not potentially wasting their time with something we may not pursue for the product. Otherwise, when would they be getting any work done towards meeting the Sprint Goal?
If you’d like to listen to learn more and advanced your Product Ownership skills, please join our Advanced Certified Scrum Product Owner training.
