One of the least discussed and most challenging roles in the agile world is that of the product owner. This role is usually selected from the ranks of product managers or business analysts and often forced into the role without any training or preparation. The typical product owner usually has very little if any experience working with agile teams and are expected to spend significant amounts of time working on the project while still performing their regular job. Often the business analyst will assume the role of product owner if the business person can’t find the time and then report back to the real product owner as deemed necessary. This substitution can lead to confusion since the business analyst is very often not the most knowledgeable about the business and obviously is not the decision maker.
With many years of experience, Robert Galen takes a comprehensive look at this very important role of the Scrum Product Owner, identifying what is expected of them while upholding agile principles. The role of the product owner should be played by the single person who is the decision maker. The product owner is the person who drives the agile team and if you have many drivers or many owners, then the team may be driven in different directions. My experience with strong product owners is that they know what they want and can define the product.
The role of a product owner can be defined and segmented it into four sections:
Deep and broad understanding of the business needs for their product,
Talking to customers and gathering information about their wants and needs,
Communicating outward regarding team, product and project state to stake-holders,
Creating a shared vision for where the market is going and how to leverage the opportunity,
Translate the vision into the features and dynamics for a product and mapping it into sprints.
Guide the iterative work as it relates to the forecast versus team velocity and release tempo,
Build a plan towards market release timing,
Create a series of steps leading to a sound release point.
Serve as a focal point within the team,
Motivate team members by providing compelling goals and objectives,
Make hard choices on priorities and business value,
Guiding and listening to the team in finding creative ways to deliver more value with less effort,
Understand the team’s strengths and weaknesses and leveraging them.
Assist in writing the requirements, use cases, user stories, etc.,
Define acceptance test and measurements,
Foster collaboration between architects, developers, and testers.