The Product Owner team

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.

 

8 responses on “The Product Owner team

  1. Yes, we have. It wasn’t until we realized that the BA actually was doing an important part of the PO work things fell into place.

    The responsibility for the contents of the product backlog and the quality of the user stories is incredibly important and that responsibility belongs to the PO. With better user stories (clearer, even sized, more stable) we have been able to increase our velocity a lot, since there is less to straighten out in the sprint and it’s easier to do sprint planning.

    Our BA spends most of his time working with the stake holders, so being part of the PO team is natural.

  2. We do it a little similar. I am the PM and have an analyst. We have a lot of stakeholders from different units in the company. We asked a spoc from each unit (you could call those spocs “Unit Product Owners) + 1 overall product owner. I schedule a meeting with all those people + my analyst to walk through the user stories, get them clear + via business value poker try to get them define priorities. These are long meetings with a lot of discussions, but all spocs get to know the concerns of other spocs. This works very well.
    When the priority-view is clear I put the stories into releases. Per release there are several sprints and at sprint planning the overall product owner has the autority, based upon BV/SP from the stories that are put into the release, to define which stories at least should be included in the sprint. When velocity is not reached yet, the project manager and its team can decide themselves to put some other stories into the sprint.

  3. Very interesting post!

    I’ve always thought what Hollywood gets this right. Each project has a producer and a director.

    Would it be fair to say: Producer == Product Manager, and Director == Business Analyst?

Leave a Reply to Hans Brattberg Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.