Who Should Be the Product Owner?

Often, Business Analysts (BA’s) become the Product Owner because they know the subject area. The change for them might be more about moving from capturing all requirements upfront for a large effort, and shifting to shorter planning horizons of release and sprint planning, clarifying small, demonstrable requirements via user stories and acceptance criteria, seeing scope as flexible, not fixed, and related – a much more collaborative and iterative means of determining estimates because of numerous options the team might come up with how they can deliver what’s wanted, and doing this via more face-to-face interaction than capturing in written form via documents and email.

A second, common issue is whether the Product Owner is given the authority to make decisions. Often the team needs decisions quickly. The BA may know the answer, but have to “get approval” before telling the team. Many times, because of the slow speed organizations and bureaucracies are used to running at, the Product Owner becomes the bottleneck for Scrum teams.

Another option for choosing the Product Owner could be Project Managers who have solid knowledge (or proven ability to quickly learn aspects of the business) and have a collaborative way of working (rather than dictatorial).

On the business side, we’ve also seen Product Managers, and heads of typical requesting groups (Marketing, Sales, or the product line or business unit) be nominated be default, since they are specifying (often in broad terms) and/or funding the effort. Although they may be one of the key people defining success, they often don’t have the time available that is required for the agile approach to requirements. They should act as a stakeholder working with a Product Owner, but still have visibility and feedback loops via the Sprint Review meetings.

If you are looking for Certified Scrum Product Owner Training, click here to check our class listings.

Learn more about CSPO certification at Scrum Alliance.