The Responsibilities of the Scrum Product Owner

By Mark C. Layton, David Morrow

Involvement begets commitment. You want to build a scrum team that can move the gears of change. The key to moving the gears of change is the product owner.

The product owner’s primary job is to take care of the business side of the project. This person is responsible for maximizing product value by delivering return on investment (ROI) to the organization. The product owner is one person, not a committee, and is a full-time, dedicated member of the scrum team. This person doesn’t own the product but takes ownership of the business-side duties, representing the stakeholders and customers.

Some of the primary responsibilities of the product owner are as follows:

  • Setting the goals and vision for the product, including writing the vision statement
  • Creating and maintaining the product roadmap, which is a broad view of the scope of the product and the initial product backlog
  • Making in-the-moment priority and trade-off decisions
  • Ensuring visibility of the product backlog
  • Optimizing the work done by the development team
  • Taking full ownership of and responsibility for the product backlog
  • Accepting proposed requirements and ordering them by priority in the product backlog
  • Setting release and sprint goals
  • Determining which product backlog items go into the next sprint
  • Handling business aspects of the project, including ROI and business risk, and interfacing with business stakeholders and customers
  • Socialize the vision and the roadmap
  • Being available throughout the day to work directly with development team members, thereby increasing efficiency through clear and immediate communication
  • Accepting or rejecting work results throughout the sprint, ideally the day they are completed

It’s shocking that organizations that plan to pour millions of dollars into a project say they don’t have the resources for a dedicated product owner to ensure that the business and technical priorities align and that the product created is the product needed. Yet many of these organizations have a project manager to direct the project. Because the project manager role doesn’t exist in scrum (relevant duties are part of the three scrum roles), the money for product owners can be taken from there.

Product owners clarify, prioritize, and set an environment for focus. They ensure that the scrum team is effective. The product owner determines what requirements are pursued and when work shifts to those requirements — that is, what and when but not how or how much. How and how much is the responsibility of the development team.

Imagine that your passion is building something. In scrum, you’d be a member of the development team. For you, the product owner is a gift. This person excels in portfolio management because he or she is empowered to make decisions, clarify, prioritize, and fight to ensure that team members focus on one project at a time. Because of effective product owners, development team members are freed from distractions and can spend more of their attention on getting their jobs done.

Both the product owner and the scrum master work to create the best environment possible for the development team to do the highest-quality work it can. The product owner handles and deflects business concerns and noise, and the scrum master ensures that other organizational interruptions don’t affect the development team.

The abstraction layer created by the product owner and scrum master doesn’t mean less business noise. It means that for the most part, the development team doesn’t have to deal with the noise.

On the other hand, development team members can contact stakeholders or other team or nonteam people directly when they need clarification on something they’re working on. This model of filtering prioritization but not clarification is like the membrane of a cell that’s designed to let certain fluids travel in one direction but not the other.

The result is that the development team is protected from outside interferences but not hindered in their quest for knowledge. These boundaries are important and integral to the successful functioning of the development team.