Agile Team Tips: Identifying the Product Owner

You are here

Agile Team Tips: Identifying the Product Owner

Advisor
Posted October 25, 2018 in Business Agility & Software Engineering Excellence
Figure 1 — The "iron triangle."



One of the first questions I often hear when explaining Agile methods is, “Who is the product owner?” Answering this question is not so simple. There is a lot of context that you have to set in order to explain the role. When rushed, the short answer is “the person on the Agile team who calls the shots relative to development priorities by acting as the voice of the customer.” This is often followed up with “of course, you know that Agile teams are self-organizing and do not have a project manager?” Then, when greeted with frowns and surprised looks, you add, “instead, the teams elect their own spokesperson.”

“Wow, this is really different,” you are probably saying. When you start thinking about the answers, you visualize the task list that the project manager performs and wonder how the work gets done. For example, some of the more important of these tasks include:

  • Define the scope and manage requirements.

  • Develop a project plan, estimate resources (time and effort), create a budget, and develop a detailed schedule.

  • Perform workload balancing by adjusting the schedule to even out the workforce loading.

  • Staff the project and arm your people with the skills, knowledge, and abilities they need to excel on the job.

  • Integrate subcontractors and consultants into the team seamlessly.

  • Provide leadership and direction for the team and hold them accountable for results.

  • Monitor performance and periodically report progress.

  • Perform risk analysis and anticipate problems and act to ward them off.

  • Buffer your people from interruptions from above and without so that they can focus on their work rather than distractions.

If there is no project manager, who does these tasks? The answer to this question is simple. Other people perform these roles when Agile methods are used. In this Advisor, we take a look at who these people are as well as their roles and responsibilities.

Agile teams deliver working products in short iterations (sprints) every two or so weeks. They differ from traditional ways that businesses develop software in their scope and focus. Agile methods are all about generating products and not about managing tasks. Their emphasis is on delivering value rather than output. They try to do this quickly and with a minimum of ceremony and overhead. To accomplish this goal, they manage what most in the industry call the “iron triangle” (see Figure 1) differently. Instead of trying to fix scope, schedule, and budget up front by freezing the requirements, they recognize the need to vary these three variables to get the most for their money. They often will elect to vary scope and fix schedule and budget through the use of backlogs. In other words, when changes in requirements threaten their delivery of product on time and within budget, they push less critical requirements and defect fixes off to a later release. Backlogs exist for both the product (user stories) and open defects. The person making the calls relative to which of these will be addressed is the product owner. He or she acts as the voice of the customer when deciding what the delivered content of a release and the relative priority of each of its features will be.
 

Figure 1 — The "iron triangle."
Figure 1 — The "iron triangle."
 

 

Product owners in Agile methods come from a variety of backgrounds. Some were business analysts, while others were users or techies with a user background. Still others are project management retreads. Independent of origin, all are gifted with the ability to communicate with the customer in a language they are accustomed to. When they are techies, they will be trained in the business and understand the applications intimately. If they were analysts, they will arrive with software backgrounds. Because all are familiar with both the business and techie worlds, they can translate from one viewpoint to the other. However, agile efforts do this collaboratively, as they rely on the team and are not leader dominated the use of backlogs. In other words, when changes in requirements threaten their delivery of product on time and within budget, they push less critical requirements and defect fixes off to a later release. Backlogs exist for both the product (user stories) and open defects. The person making the calls relative to which of these will be addressed is the product owner. He or she acts as the voice of the customer when deciding what the delivered content of a release and the relative priority of each of its features will be.

In theory, product owners are supposed to work as full-time members of the delivery team. The reason for this is simple. As the voice of the customer, they are often called upon by team members to explain what the requirements mean and what needs to be done, how to test them, and what to do to make them work right when placed in operation. Unfortunately, this does not always happen — mainly because there are not enough of them to go around. In response, firms share those that they have or ask real customers to answer the questions the teams may have relative to the product. This approach rarely works because either the customers are not available when needed or they just do not want to be bothered. This leads to firms using unqualified people to fill the role. My feeling is that sharing is the better option.

Some of the many tasks that the product owner performs include the following:

  • Maintain the product vision by keeping the product roadmap up-to-date.

  • Participate in the release planning and use this activity as a means to help plot out the contents of the delivery.

  • As planning progresses, use workshops and standups as an opportunity to further refine the stories and manage and groom the product and defect backlogs.

  • Prioritize needs by juggling the constraints of the iron triangle so that the right features are delivered per the existing budget and schedule.

  • Help to elaborate and maintain the flow between stories across iterations as they unfold.

  • Participate in the development of acceptance criteria as the stories are written and refined.

  • Understand and anticipate the customer’s needs and communicate them to developers.

  • Act as the liaison and facilitate communications between the stakeholders (customers, users, executive management, marketing, etc.) and the teams.

  • Participate in the release retrospective and demo and use these sessions as opportunities for improvements.

As you can see, besides having a different role, the product owner has much less power and responsibility than a project manager. The reason for this is simple: Agile developments are self-managed. The product owner, scrum master, and team share this management role jointly. While the product owner focuses on product content and priorities, the scrum master’s job is one of facilitation and coordination. In contrast, the team’s focus is on developing a working product per the timelines and budgets that they have committed to.

The closest thing to project management in Agile developments occurs when large or enterprise-wide efforts are being pursued. On such jobs, a program management office (PMO) has been established to address the product requirements, architecture, coordinate interfaces, synchronize schedules, and harmonize activities when multiple teams are working in parallel. Since the PMO and product owner share content authority, their roles need to be explicit; else conflicts can arise. Typical roles are listed in Table 1.
 

Table 1 — Typical PMO, product owner, and development team roles.
Table 1 — Typical PMO, product owner, and development team roles.
 

Agile-at-scale development makes the picture more complicated. That is the reason why such efforts employ more people, ceremony, and overhead to get the job done. These items are collectively called the communications burden. The net result of adding such a burden is that as developments grow in size and complexity, so do the negative impacts. To overcome such impacts, leadership needs to push the organizations so that its efforts remain Agile in spirit and collaborative by design. Such a push often flounders when organizations fight changes and the status quo rules. When such resistance is successfully overcome, the organization can overcome the negatives and deliver products that generate maximum business value for the organization. But, to do so means embracing Agile as a mindset throughout the organization.

About The Author

Donald Reifer's picture

Donald J. Reifer is recognized as one of the leading figures in the fields of software engineering and manage­­ment, with more than 40 years of progressive management experience in both industry and government. He has managed major R&D initiatives and is often called upon by clients to review troubled programs, examine red team proposals, and perform competitive assessments with an emphasis on benchmarking and ROI analysis. Besides being... Read More

Leave a reply

Your email address will not be published. Required fields are marked*