The Scrum Product Owner | Luniel's Portfolio

Article: The Scrum Product Owner

A lot of confusion exists about what the role of the Scrum product owner is. While some people correctly understand it in the way it was intended by the creators of Scrum, as documented in the official Scrum Guide, most people confuse this role with that of a product manager or a software development manager. This confusion stems from not understanding that Scrum is a project management framework.

However, once Scrum is understood in this manner, it's possible to correctly frame the role of the product owner for both small and large scale implementations of Scrum.

The first and primary responsibility of the product owner is managing the "Product Backlog" from which the Scrum Team is working. Without this backlog, the adoption of Scrum is void. It is the Scrum equivalent of the traditional project plan, albeit a "living plan" that changes constantly as scope is fed into it, defined, refined, reprioritized, developed, and adapted as needed.

There is a fundamental difference between the Scrum product backlog with backlog items and the traditional project plan with tasks that must be understood in order to understand the role.

Traditional Project Management

A project has a defined beginning and end in time, and as such it has a defined scope. The project ends once all the scope has been implemented. The project manager works with stakeholders and implementers to get the scope defined and to build a project plan that contains tasks with inputs and outputs, which are usually completed in specific stages of the project.

The project manager is then responsible for making sure that the tasks are planned and delivered per the plan project, and within any project stages that may have been defined. Once the project has been completed, the project manager moves on to the next project, regardless of who will be working on that project.

Thus, the project plan, or project backlog if you will, is specifically created for the project and is archived or discarded once the project is complete.

Project Management Using Scrum

It was within the world of traditional project management that Scrum was born. However, in Scrum, the product backlog is the primary container for all the project deliverables, called product backlog items (PBIs). Most software projects were originally aimed at creating software products, hence the name "product backlog".

The project timeline is broken into stages that are time-bound, anywhere from one week to 30 days, with most teams adopting a regular 2-week cadence. In Scrum, these stages are called "sprints". For each sprint, a sprint backlog is then created with the work that the team has selected to achieve the goal that the Product Owner has established for that Sprint. In this manner, the Scrum team incrementally completes the project by completing sprints.

The Scrum Product Owner manages the "project" by managing the product backlog by defining backlog items, refining them so as to be completed within a sprint, prioritizing them to maximize the value created by the team, and adapting the backlog as needed based on inspection of the work completed at the end of each sprint as well as the changing needs of the customer/stakeholders.

Thus, the product backlog is specifically created for the purpose of developing the software product. If you're interested in the origin of the name "Scrum" and the concept of sprints, I recommend reading The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka, and as a bonus, you'll learn the true origin of the concept of cross-functional teams (in case you ever wondered about that).

Fast-Forward

Initially, the product backlog would be empty by the time the "project" of developing the software product had been completed. In time, however, teams started adopting Scrum as their standard way of working, and today the "product backlog" has essentially become the "team backlog". All working coming to the team has to come via the Team's "product" backlog, even though most modern software teams no longer build entire products on their own simply because today's software solutions tend to be enormous collections of individual software capabilities that are developed and continuously evolved by multiple teams.

Thus, the Scrum product owner has essentially become the role that manages the Scrum team's backlog; a living, breathing backlog of work that constantly shifts to accommodate the potentially endless changes that need to be made to the software in order for it to remain useful.

Make no mistake, this is a demanding role that usually demands someone dedicated full-time to it. The work of meeting with stakeholders and development teams to capture and clarify requirements, prioritize the work, refine the backlog items, assess the completed work for completeness, and generally act as the single point of contact for all the work the team has to do, does not leave much time for other responsibilities. It also requires very specialized skills to craft and maintain software requirements and to contribute to the product knowledge management.

A Summary of the Scrum Product Owner Role

I've summarized the role of the Scrum product owner from as follows:

The one person responsible and accountable for managing the "Product Backlog" from which the Scrum Team is working.
The one person who must be addressed by those wanting to change a product backlog item’s priority.
The one person who knows all the work of the team, along with what the value of the work is, the reason for the specific ordered, and who the business stakeholders are, because the development team's work comes only from this one source and no-one can force them to work from a different set of requirements.
Maximizes the value of the product resulting from work of the development team.
Makes sure product backlog items are expressed clearly.
Makes sure product backlog items are ordered to best achieve goals and missions.
Optimizes the value of the work the development team performs.
Makes sure the product backlog is visible, transparent, and clear to all, and shows what the Scrum team will work on next.
Uses techniques for effective product backlog management, knows how to arrange the product backlog to maximize value, understands product planning in an empirical environment, and understands and practices agility.
Makes sure the development team understands items in the product backlog to the level needed.
Uses the product backlog to make changes without impacting the work items that the development team is working in the Sprint (the sprint backlog items).
Provides goals, scope, and product domain in a way that is understood by everyone on the Scrum team as well as possible.
Establishes a Sprint goal that provides the development team with a coherent goal to work together rather than on separate initiatives, and as the team performs their work, collaborates with them to negotiate the scope of the sprint backlog within the sprint towards the completion of the goal, and enables them to stop working on obsolete work, especially in the event that the sprint goal becomes obsolete.
At the end of each sprint, during the Sprint Review event, gives stakeholders and the development team a sense on projected target and delivery dates based on progress to date.
Last but not least, the product owner does not manage the development team, and instead manages the team's work by managing the product backlog.