The Role of the Product Owner in Scrum

[ad_1]

There has been a lot 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 in blogs, twitter and other social media. I don’t think there is a “best practice” answer. Let’s look at what we do know and then see if we can find an answer. The goal of the PO must be to deliver the right business value. To do this they, engage the team(s) to create solutions that deliver the business value.

They are listening to and evaluating the needs of the stakeholder community. They must have a great business sense and understand their market and customers. They must understand what is technically possible. From all this input they deliver a stream of input to the team about what the priorities are. They are constantly updating this information and evaluating the output of the team to check it for completeness and correctness. While the team has the same goal of delivering business value, their problem space is much different. In all but trivial domains and projects this requires a team approach. Team building is not about money. Ask Yankees owner George Steinbrenner!

Team building is not about technology or computers. Team building is about people. However the problems faced by the team in delivering the solutions is about technology. The team takes direction (course) from the PO, but the he or she cannot work in the engine room of the Scrum ship! It is not that they are not qualified (they may not be) , it is just that their primary role is so important and time consuming they would be neglecting that duty if they did. The team must take the direction (course) from the PO. Their work demands their complete attention. We know all this. The real question is how do we best create the communication and feedback that the Product needs so that the business can be successful and thrive? Scrum provides a great starting point. Lean helps us understand the product view and the flow of business value. The process of planning a product release must 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 core to team building. Scrum tells us that the product management team can listen to this meeting, but it is the Team’s meeting. If I were a Product Owner, I would be at the daily stand-up if at all possible. The Sprint review and demo are 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 Sprint output. The Sprint retrospective is a Team meeting. This meeting is primarily focused on team building and process refinement. This needs to be a private Team meeting.

Can the Product Owner be a benefit to the Team in the daily process of developing the solution? That depends. How much time do they have? How well do they understand the technology? How well do they work within the Team? No one can know the answers to these questions without observing the Product Owner and the Team. Will the Product Owner be a helpful, accepted and valuable member of the Team? That depends. Can the Product Owner deliver the stream of information and decisions to the team with a high level of accuracy? That depends. With all these unknowns, I don’t believe that anyone can say how any particular Product Owner and Team will be able to work together best without some first-hand knowledge.

[ad_2]

Source by Rod Claar