The Product Owner Team’s 4 Rules of Engagement

Here are four rules of engagement that must be considered as the Product Owner team forms, and begins to operate:

1. The Product Owner Team is not an ivory tower with unilateral decision making authority

While this team has to be empowered to make decisions, it is incumbent on everyone involved to approach the business stakeholders to create shared understanding and build consensus across stakeholders with competing demands and business objectives.  Solutions should be as inclusive as possible.

2. The Product Owner Team does not work in silos

The team members are collectively responsible for the output of the Product Owner team.  This team should speak with one voice to the business and the Scrum Teams.  While team members may work independently to gather information, the results needs to be brought back to the team for full consideration with the larger group.

3. The Product Owner Team does not commit on behalf of the Scrum Teams

The Product Owner team is responsible for making high level estimates and defining a release candidate.  This is more an exercise to determine what is ‘out’ rather than what is ‘in’.  Only after each team has reviewed it’s backlog and provided detailed story point estimates, and assessed those estimates against their established velocity, can we collectively make even a high-level estimate back to the business.

4. The Scrum Teams are the customer for User Stories

It is not up to the Product Owner team to decide what is good enough for each Scrum Team.  The Scrum Teams will decide if the user stories meet the threshold of the INVEST criteria.  This may require a different level of specificity from team to team.  The goal would be for some degree of standardization over time, but this has to be driven based on the needs of each individual team.

Okay… so what else?  If you were going to put a Product Owner team in place, what kinds of operating principles or design constraints might you be inclined to impose?