Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 147 posts at DZone. You can read more from them at their website. View Full User Profile

Product Owner Team Design Considerations

03.31.2011
| 1611 views |
  • submit to reddit

There are some rules of engagement that need to be considered as the Product Owner team forms and begins to operate:

  1. This 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?
References
Published at DZone with permission of Mike Cottmeyer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Mark Anthony replied on Fri, 2012/04/13 - 10:11am

I’ve only taken a few minutes to review your site, so perhaps I have not done it justice, but I’m not seeing anything on updating SOPs and who is responsible for this effort.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.