Get certified - Transform your world of work today


The Product Owner on One Page

Overview of the Product Owner Role

15 December 2010

Roman Pichler
Pichler Consulting Limited

The following diagram summarises the product owner's responsibility together with the role's key activities and artifacts.


You can find out more about the product owner role in my book Agile Product Management with Scrum (Addison-Wesley 2010).

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (1 ratings)


Arran Hartgroves, CSP,CSM, 12/18/2010 5:10:42 AM
I'm trying to get this role fully recognised in my organisation. It's surprising how many teams have product owners who only collaborate/elaborate with requirements. Getting the full role and responsibilities (and time commitments) is a hard sell, and I've noticed other roles e.g. BA adopting these activities due to ideal PO's being too busy.

I might write about how component, non-user facing teams can get team members such as architects to adopt more of the PO role (within the technical community, their time is often easier to get and as they set the vision often where I work, they seemed a good choice). Would you agree with this?
Roman Pichler, CST,CSP,CSM,CSPO, 12/20/2010 4:03:59 AM
Hi Arran, Fully establishing the product owner role is a challenging process for most organisations I have worked with. It takes time and support from the individuals playing the role and the leadership team. It sounds like your organisation may benefit from having product owners who take care of the strategic and market-facing activities as well as the tactical, development-facing ones.

With regards to component teams, an architect or senior developer may be best suited to play the role as you suggest. But before you go down this route, consider employing feature instead of component teams. The former tend to be preferable for a number of reasons. For instance, they simplify product backlog grooming and product owner collaboration. Speaking of which: If you employ multiple teams, form a hierarchy of collaborating product owners one overall or chief product owner.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up