3 Keys to Effective Product Ownership

In agile and Scrum, the Product Owner is, by far, the most demanding role. The PO acts as a go-between for communication between the customer and the development team, but, if the whole project goes to the dogs, he or she is the individual responsible for the disaster. But that responsibility doesn’t necessarily mean that the PO is in complete command of every situation. Sometimes, POs need help from the developers on the team as well as the ScrumMaster to provide them with the kind of information they need to succeed. For instance, the Product Owner must possess the ability to prioritize. If a member of the development team goes to the PO to ask which features of a given product are most vital, an answer like “They’re all equally important” doesn’t help anybody. Teams need to know what functionality is most essential to the product, so they can pursue that goal as soon as possible. A Product Owner must be able to articulate requirements—not “sketch out,” not “summarize,” but articulate. Since the development team depends on the PO to relay information, his or her ability to do so in a way that accurately conveys the customer’s vision is crucial to the success of the project. Likewise, a Product Owner also needs to be equally adept at stepping back and analyzing the big picture. This perspective is what allows release planning, strategic initiatives, and more. If a Product Owner cannot operate at that level, then he or she may not be cut out for the role. How can team members help ensure that a Product Owner is doing all of these things? By asking questions. When gathering requirements, developers should work to understand the customer vision by asking the Product Owner to share what he knows. Over time, developers will cultivate skills to help draw out information from the Product Owner. For instance, when attempting to assign a priority to a particular story, a developer may want to ask the PO about its importance in relation to several other stories, in order to softly assemble a hierarchy. Through these conversations, developers can train their Product Owner about what kind of information is most valuable to successful development.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.