The Role of the Product Owner in Scrum

Much has been written about the role of the Product Owner (PO) in Scrum over the years and it seems to me that in the last month or so the question has received a lot of attention on blogs, Twitter and other social media. I don’t think there is a “best practice” answer. Let’s see what we know and then see if we can find an answer. The goal of the purchase order should be to deliver the right business value. To do this, they engage the team(s) to create solutions that deliver business value.

They are listening and assessing the needs of the stakeholder community. They must have a strong business sense and understand their market and customers. They must understand what is technically possible. From all these inputs, they provide a flow of information to the team about what the priorities are. They constantly update this information and evaluate the team’s results for completeness and accuracy. While the team has the same goal of delivering business value, their problem space is very different. In all but the trivial domains and projects, this requires a team approach. Team building is not about money. Just ask Yankees owner George Steinbrenner!

Team building is not about technology or computers. Team building is about people. However, the problems the team faces in delivering the solutions have to do with technology. The team takes direction (course) from the PO, but he or she can’t work in the engine room of the Scrum ship! It’s not that they’re unqualified (they may not be), it’s just that their primary role is so important and time-consuming that they’d be neglecting that duty if they did. The team must take the direction (bearing) from the PO. Your work demands your full attention. We know all this. The real question is how do we best create the communication and feedback that the Product needs for the business to succeed and prosper? Scrum provides a great starting point. Lean helps us understand the product vision and business value stream. A product launch planning process should include input from the team. Sprint planning is a cooperative process between the team and the product owner.

The daily stand-up is a team meeting that is critical to team building. Scrum tells us that the product management team can hear this meeting, but it is the Team meeting. If I owned a product, I’d be in daily stand-up if possible. The Sprint review and demo is all about the team getting feedback from the product owner and anyone interested. If I were on a team, I would NEVER go into a Sprint review without knowing what the Product Owner thought of the outcome of the Sprint. The Sprint retrospective is a team meeting. This meeting is primarily focused on team building and process refinement. This must be a private team meeting.

Can the Product Owner be a benefit to the Team in the daily process of developing the solution? It depends. How much time do you have? How well do they understand technology? How well do they work within the team? No one can know the answers to these questions without looking at the Product Owner and the Team. Will the product owner be a useful, accepted and valued member of the team? It depends. Can the Product Owner deliver the flow of information and decisions to the team with a high level of accuracy? It depends. With all these unknowns, I don’t think anyone can say how a particular Product Owner and Team will be able to work better together without first-hand knowledge.

Leave a Reply

Your email address will not be published. Required fields are marked *