Product Owner

• Accountabilities
  • Maximizing the value of the product resulting from the work of the Scrum Team
  • Effective Product Backlog management
    • Developing and explicitly communicating the Product Goal
    • Creating and clearly communicating Product Backlog items
    • Ordering Product Backlog items
    • Ensuring that the Product Backlog is transparent, visible and understood
  • May do the above work or may delegate the responsibility to others. Regardless, remains accountable
  • The Product Owner is one person, not a committee
  • For Product Owners to succeed, the entire organization must respect their decisions
  • Those wanting to change the Product Backlog can do so by trying to convince the Product Owner
  • responsible for:
    • managing expectations of customers, users and other stakeholder
    • Product Backlog Management
    • deciding what to build when and what not to build
    • decide what to deliver (release) to customers/users, in what order to deliver to customers/users and when to deliver (release strategy and release plan)
  • The evolution of the PO
    • The pattern
      • how a PO grows in his role
      • describes how, many organizations have implemented the role of the PO
      • describes the required 'features' of a PO.
      • The pattern is incremental, at each step the benefits grow
      • Each version/stage is an upgrade of its predecessor and incorporates all qualities of the previous version
    • Scribe (receiving)
      • As a first attempt of implementing the PO role
      • start with someone with strong analytic skills: often a member of the Scrum Team that was used to writing requirement specs or someone who used to be the 'Business Analyst'
      • get started with the creation of a Product Backlog
      • limited benefits, often need others (marketing, sales, product/project managers, steering committees, etc) to answer difficult questions
      • This delegated decision making often leads to a disruption of the flow, bottlenecks, large piles of stocked work, and a slow generation of Business Value
    • Proxy (receiving)
      • In order to solve the communication problems of a Scribe
      • update the role with a senior analyst that has strong communication skills
      • The focus of a Proxy shift from creating Product Backlog items towards creating Product Increments
      • The benefits of a Proxy are better since they are more connected to the business than the Scribe. Although the delays, waiting time, and hick-ups will decrease, many of those remain
    • Business representative (initiating)
      • A problem with the Proxy (and Scribe) is that the business (often marketing & sales) is disconnected from the IT department
      • organizations understand that they need to break down the inter-departmental barriers, they send in someone from marketing/sales/product management to fill in the PO role
      • From this moment on the Scrum Team consists of people from all parts of the organization, and not only from the IT department
      • benefits increase since there is a broader collaboration
      • Now there is direct availability of functional knowledge & stakeholder expectations
      • Yet, the business representative still has limited autonomy, since marketing\sales\product management department is still the real authority
    • The sponsor (initiating)
      • Once a Business Representative has felt the pain of continuously asking the business departments to make decisions, they fight to get some mandate
      • Once the business departments dare to give control to and trust the Business Representative, they are upgraded to a Sponsor
      • It works better, has the trust and the mandate to take decisions
      • A mandate is a signal that the role is taken more seriously
      • The issues mostly come down to a need for lobbying for a budget
      • A sponsor still needs to negotiate to free up money from the different business departments. Maybe he can already decide on how to spend the money for his own department, but there are still other departments that need to be convinced
    • Entrepreneur (initiating)
      • fully responsible for functionality and budgets
      • mini-CEO, a real owner over the product
      • responsible for all aspects, like marketing, competition, users, legal & finance within the scope of his product. His professional life is dedicated to the well-being of the product
      • Unfortunately, still a rare species, organizations are often not ready to delegate this kind of control
    • Characteristics of a great Product Owner
      • Embraces, shares and socializes the product vision
      • Exceeds the customer’s expectation
      • Is empowered
      • Orders the product backlog
      • Prefers face-to-face communication
      • Knows modeling techniques
      • Shares experiences
      • Owns user story mapping
      • Has a focus on functionality
      • Is knowledgeable
      • Understands the business domain
      • Acts on different levels
      • Knows the 5 levels of Agile planning
        • Vision, Roadmap, Releases, Sprints, Daily Scrum
      • Is available
      • Is able to say 'no'
      • Acts as a "Mini-CEO"
      • Knows the different types of valid Product Backlog items
      • Takes Backlog Refinement seriously
    • Why Only ONE Product Owner
      • Scrum prescribes one person in the role of PO. Not multiple people, not a committee, just one person
      • many companies that fail to implement this specific Scrum guideline. Apparently, according to most companies, this is one of those things you need to tweak “to make Scrum work in your context”
      • The apparent need for multiple POs
        • When companies need to scale their development, they tend to copy Scrum Teams, including the PO
        • They soon find out that the PO role does not scale that well by multiplication
        • As they lose transparency over responsibilities, they try differentiating the PO role in various types of POs such as Feature Owners, Epic Owners, Component Owners and more. They are looking in the right direction but choose the path of complexity instead of simplification
        • In many cases not a problem in giving authority and accountability for the whole product to one person
        • But they feel having multiple POs and multiple product backlogs is a necessity for various reasons:
          • The Scrum Guide says one PO per team, we must have multiple POs as we have multiple teams. (This is a myth; One Product Backlog means we need one Product Owner)
          • The domain knowledge for a complex product like ours is too vast for one person to grasp
          • The workload to produce all user stories is too big and cannot be handled by one person
          • There are too many meetings in Scrum for a single PO to attend
          • With multiple POs the PO-availability for teams can be provided at the required level
          • It is easier to have many POs as it avoids the fight over who should become the one real PO
          • we thought we needed one PO per team. Now that they are here, cannot just send them away
        • Downsides of having multiple POs
          • … encourages micromanagement of team: In a Product Owner per team situation
            • the PO becomes the person that spells out all the detailed specs (user stories)
              • contract negotiation game
            • growing absence of domain expertise in the teams
              • team stick to executing tasks (opposed to solving customer problem), which re-enforces the need for more PO’s
            • reduces opportunities for learning and self-organization
            • normally suggest to make the PO’s part of the development they work with. They will get the opportunity to become multi-skilled development team member with a focus on analysis
          • … requires coordination and alignment
            • The POs decide in a PO team to agree who takes care of which items on the PB
            • customer features are sliced, each PO gets their own sub-scope of the customer value in a PB
              • The work is sliced on arbitrary and artificial grounds, creating a coordination need to deliver an integrated product by the end of the sprint
              • If the coordination need is high between PO’s, probably the PB has not been sliced to optimize for minimal dependencies and the teams are not structured to serve that goal
            • prioritization is decentralized and will lead to local optimization per backlog
              • This introduces asynchronous dependencies between teams, as some teams are “full” and cannot do certain work other Teams depend upon
            • Teams don’t have a whole product view and lose track of what is customer value
            • Having only one PO managing a single PB for multiple teams creates the transparency required for proper empiricism
          • …bring unclear responsibility and ownership
            • One PO means that one person is accountable for the ROI on the product under development
            • With multiple Product Owners, accountability, responsibility and ownership are oblique
            • Management has a tough job on Product development as there is no “single neck to wring”
            • Multiple PO’s stimulates part-time jobs, by adding the PO work to someone’s existing workload
            • suggest to restore transparency by extending the DoD gradually to include the work described in the additional backlogs or simply merge them into one single PB
          • What if it fails? If your PO cannot handle the work involved managing the product
            • Being a PO is a difficult job and not everybody can do it. Hire someone else, or maybe you can fix it by sending the PO to a proper training
            • Reduce the number of features (user stories) in the backlog, they are probably too detailed
            • Stimulate “prioritization over clarification”
              • Reduce the level of detail at which the PO is dealing with features by explicitly bringing the clarification responsibility in the team
              • The PO can help by connecting the team to a stakeholder or customer
            • Limit the planning horizon to no more than 2 to 3 sprints of work ahead, preparing more work is likely to result in waste
            • Prevent the Product Backlog from spawning
              • by extending the DoD, continuously reducing technical debt with merciless refactoring and strict bug policies
            • Conclusion
            • The 3Vs
            • 10 Tips for PO on Agile Product Management
            • 10 Tips for PO on Value
            • 10 Tips for PO on Stakeholder Management
            • 10 Tips for PO on Scrum Framework
            • 10 Tips for PO on Product Backlog Management