In my opinion, the Product Owner (PO) role is the most demanding one in Scrum, since the PO needs to have so many talents and you rarely find all of them in one single person.

You need to know

• the business (what makes money for the company)
• the end users (what makes them spend their money)
• the stake holders (what drives them)
• the development team (how software is made).

You also need to know how to translate all of the above into user stories. On top of that, many POs are also responsible for finding funding for their product and development team within the company.

It’s very difficult to find one single person that does all this well, so in my current team we formed a PO team instead.

Our Product Owner team consist of two people: a business analyst and a project manager. This has turned out to be a really good combination.

The business analyst specializes in turning customer and stake holder needs into requirements. In our case, requirements are expressed as user stories, usually in the popular form “As a <role> I want to <do something>, so that <explanation why>”. Writing   user stories doesn’t come naturally to everyone, it requires practice and skills, so it’s really good to have the business analyst working with the stake holders documenting requirements this way.

To be able to write consistent user stories, our business analyst, working with the stake holders,  has made a domain model explaining all the concepts used and their relations. This model is not a data model for implementation, it’s more of a dictionary defining what we mean when we discuss various aspects of the application. This has proven to be very useful.

In essence, in our PO team our business analyst is responsible for the content of the product backlog. Every time requirements are captured and put into user stories they are reviewed (or written) by him.

The project manager in the PO team also works with the stake holders, but discusses priorities, funding and external dependencies (such as roll out of new functionality in the organization). This requires a different set of skills compared to doing business analysis. This is about in which order and when things are done and delivered.

In essence, in our PO team, the project manager is responsible for the release plan in the product backlog as well as ensuring funding for the user stories. In this organization it’s the stake holders that have the budget and not the PO.

Our PO team works in pairs having two different types of backlog grooming meetings with the stake holders every week.

The first meeting is about the content of the product backlog. They go through all the user stories clarifying, adding and removing stories as new opportunities come up and other become obsolete.

The second meeting is about prioritizing the product backlog and making a release plan for the next three sprints. Market windows, campaigns and product launches are taken into account when creating an absolute priority for each user story (that will last at least until the next meeting).

As I have described in an earlier post, the product backlog is posted on a wall and stored electronically in a PowerPoint document.

Having the PO team working as a pair has proven to be very successful. Each member contributes with his skills and as we know from pair programming two heads think better than one.

Q: Who has the final word about the priorities?
A: The project manager, since he is responsible for the release plan and funding.

Q: Are the ever confilcts between the two?
A: Not more than usual when two people discuss.

Q: If the team receives a task/user story by someone outside the sprint, who do they talk to?
A: The project manager, since it’s a priority issue and it affects the current sprint and the release plan.