A Scrum Product Owner checklist

After my last post on the role of the Scrum Master I have been asked if I could write a similar role description for the Scrum Product Owner. 

Here’s my view of the role: 

The Product Owner

The product owner is a visionary who can envision the final product and communicate the vision. 

The product owner is also the person who sees the vision through to completion. This includes describing features, collaborating and communicating with the delivery team, accepting or rejecting work results, and steering the project by tracking and forecasting its progress. 

The Product Owner points the team at the right target, the Scrum Master helps the team get to the target as efficiently as possible. In other words: The product owner is the what-person, the Scrum team are the how-people.
 

In general the Product Owner …

 

  • is responsible for that the team builds the right product
  • manages ROI and makes sure to deliver business benefits
  • is responsible for that budget constraints are met
  • is responsible for that what the team is asked to build is aligned with what the sponsor, stakeholders and users want
  • provides boundaries to describe the realities within which the vision must be realised (e.g. time frames, external quality)
  • makes sure management, stakeholders, sponsors are informed and the vision is aligned with their wishes

 

As a Product Owner you do …

Some activities I would expect from an experienced Product Owner:

  • Provide a vision for the product
  • Communicate the project vision to the team
  • Motivate the team to subscribe to the product vision
  • Communicate the business benefits of the entire product and each individual feature
  • Create and maintain the product backlog
  • (the product owner can delegate some of the work of writing user stories to a BA but the Product Owner is still responsible that the work is being done and is being done properly)
  • Continuously groom the product backlog
  • Prioritise the product backlog
  • Define releases
  • Define release and sprint goals
  • Continuously answer questions to add detail to requirements
  • Accept/reject developed user stories at the end of the sprint (or during the sprint)
  • Communicate about the project within the organisation (e.g. demo attendance and invites, forecasting, management reporting, sponsor liaison )

 

Here are some great resources I can highly recommend:

 

 

Sandy Mamoli
4 Comments
  • mohammed ali
    Reply

    Great

    May 18, 2016 at 10:42 am
  • Mary Duran
    Reply

    Great breakdown of the role description

    September 1, 2016 at 6:49 am
  • Scott Walburn
    Reply

    Very helpful breakdown of POD activities

    September 23, 2016 at 6:48 am
  • Peter Moreno
    Reply

    sprint goals are to be defined by the team, not the PO, this can brake self-organization and empowerment of the team. The PO provides boundaries to the team using a clear product backlog and helping on the formulation of the sprint backlog.

    June 1, 2017 at 12:40 am

Post a Comment