Over a million developers have joined DZone.

Product Owner Team Design Considerations

DZone's Guide to

Product Owner Team Design Considerations

· Agile Zone
Free Resource

Speed up delivery cycles and improve software quality with TestComplete. Discover the most robust automated testing tool for end-to-end desktop, mobile, and web testing. Try TestComplete Free.

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?

Release quality software faster with TestComplete. Discover how to decrease testing times and expand test coverage with the most robust automated UI testing tool. Try free for 30 days.


Published at DZone with permission of Mike Cottmeyer, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}