Chapter 9. Product Owner

In this chapter I expand the description of the product owner role. I begin by explaining the purpose of this role relative to other Scrum roles. Then I detail the principal responsibilities and characteristics of a product owner. Next I present a “day in the life” of a product owner over the course of multiple weeks. I then discuss who should be a product owner for different types of product development. I conclude by describing how the product owner role can be combined with other roles and how it can be scaled up into a product owner team.

Overview

The product owner is the empowered central point of product leadership. It is one of the three collaborating roles that constitute every Scrum team (the others being the ScrumMaster and the development team).

The product owner needs to look in at least two directions simultaneously (see Figure 9.1).

Figure 9.1. The product owner faces two directions simultaneously.

On one hand, the product owner must understand the needs and priorities of the organizational stakeholders, the customers, and the users well enough to act as their voice. In this respect the product owner acts as a product manager, ensuring that the right solution is developed.

On the other hand, the product owner must communicate to the development team what to build and the order in which to build it. The product owner must also ensure that the criteria for accepting features are specified and the tests that verify those criteria are later run to determine whether the features are complete. The product owner doesn’t write detail-level tests but ensures that the high-level ones are written so that the team can determine when the product owner will consider the feature complete. In these respects the product owner is part business analyst and part tester.

Principal Responsibilities

Figure 9.2 illustrates the principal product owner responsibilities.

Figure 9.2. Principal product owner responsibilities

This is clearly a full-time role with significant responsibilities. As a matter of fact, when you read the description that follows, you might start to think that it is not practical for one person to handle all of these responsibilities or to have all of the attributes necessary to be successful in the role. In most cases a single person can and should fill the product owner role; however, under certain circumstances, product owner teams or product owner proxies might be practical. Both concepts will be covered later in the chapter.

Manage Economics

The product owner is responsible for ensuring that good economic decisions are continuously being made at the release, sprint, and product backlog levels (see Figure 9.3).

Figure 9.3. The product owner manages economics.

Release-Level Economics

At the release level the product owner continuously makes trade-offs in scope, date, budget, and quality as a stream of economically important information arrives during product development. Trade-offs made at the beginning of a release might no longer be appropriate in the presence of new information that arrives during the release.

For example, what if several weeks into a six-month, fixed-date development effort we recognize an opportunity to increase revenue by 50% if we take one extra week (4% schedule slip) to add a newly identified feature to the release? Should we trade one week’s time and the additional cost for the extra revenue? The product owner oversees this decision. In many cases he can unilaterally make the decision. Other times the product owner might recommend a decision but still work with others to secure their input (and at times approval) to execute the decision.

Also, at the end of every sprint the product owner oversees a decision as to whether or not to fund the next sprint. If good progress is being made toward the release goal or the next sprint is otherwise economically justified, the next sprint will be funded. If poor progress is being made or the economics don’t support additional expenditures, the effort might be canceled.

A satisfied product owner might also oversee a decision to stop funding further development at the end of a sprint if the product is ready to ship and additional expenditures simply aren’t justified. For example, let’s say we planned for a ten-sprint release. After sprint 7, the product owner reviews the remaining product backlog items and concludes that the cost to create those items is greater than the value they deliver. The product owner might conclude that shipping the product early instead of continuing with the original ten-sprint plan is economically more sensible. This flexibility to deliver early is enabled by ensuring that the higher-value items at the top of the product backlog are worked on first and the team is completing work each sprint in accordance with a strong definition of done.

And, of course, the product owner might also conclude that we should stop funding at the end of a sprint because core economic properties have changed. For example, what if we are creating a country-specific product and a regulatory agency in that country revises its laws, making it unprofitable or perhaps even illegal for us to sell the product? In cases like these, a product owner might oversee canceling the development effort even if things are otherwise going well.

Sprint-Level Economics

In addition to release-level economics, the product owner also manages sprint-level economics, ensuring that a good return on investment (ROI) is delivered from each sprint. Good product owners treat their organization’s money as if it were their own money. In most cases the product owner knows the cost of the next sprint (the duration and team composition of the sprint are known). With this knowledge the product owner should ask himself at sprint planning, “Would I write a check out of my own bank account equal to the cost of this sprint to get the features that we’re planning to build in this sprint?” If the answer is no, a good product owner wouldn’t spend the organization’s money either.

Product Backlog Economics

As I discussed in Chapter 6, the product owner is responsible for prioritizing the product backlog. When economic conditions change, the priorities in the product backlog will likely change as well.

For example, let’s say that at the start of a release the product owner believes a feature is valuable to a large percentage of the target users and the team believes that only a modest effort is required to create it. After a few sprints, however, the team discovers that the feature will require a large effort to complete and is valuable to only a fraction of the target users. Because the cost/benefit ratio of this feature has dramatically changed, the product owner should reprioritize the product backlog to reflect this knowledge—perhaps by dropping the product backlog items associated with the feature.

Participate in Planning

The product owner is a key participant in the portfolio-, product-, release-, and sprint-planning activities. During portfolio planning (see Chapter 16), the product owner works with internal stakeholders (perhaps an approval committee or governance board) to position the product correctly in the portfolio backlog and to determine when to start and end product development. During product planning (see Chapter 17), the product owner works with the stakeholders to envision the product. During release planning (see Chapter 18), the product owner works with the stakeholders and the team to define the content of the next release. During sprint planning (see Chapter 19), the product owner works with the development team to define a sprint goal. He also provides valuable input that enables the development team to select a set of product backlog items that the team can realistically deliver by the end of the sprint.

Groom the Product Backlog

The product owner oversees the grooming of the product backlog, which includes creating and refining, estimating, and prioritizing product backlog items (see Chapter 6). The product owner doesn’t personally perform all of the grooming work. For example, he might not write all of the product backlog items; others might contribute them. The product owner also doesn’t estimate the items (the development team does that) but is available for questions and clarification during estimation. The product owner is, however, ultimately responsible for making sure that the grooming activities take place in a way that promotes the smooth flow of delivered value.

Define Acceptance Criteria and Verify That They Are Met

The product owner is responsible for defining the acceptance criteria for each product backlog item. These are the conditions under which the product owner would be satisfied that the functional and nonfunctional requirements have been met. The product owner may also write acceptance tests corresponding to the acceptance criteria, or he could enlist the assistance of subject matter experts (SMEs) or development team members. In either case, the product owner should ensure that these acceptance criteria (and frequently specific acceptance tests) are created before an item is considered at a sprint-planning meeting. Without them, the team would have an incomplete understanding of the item and would not be ready to include it in a sprint. For this reason, many Scrum teams include the existence of clear acceptance criteria as an item on their definition-of-ready checklist (see Chapter 6).

The product owner is ultimately responsible for confirming that the acceptance criteria are met. Once again, the product owner may choose to run acceptance tests himself or may enlist the assistance of expert users to help confirm that the product backlog item meets the conditions of satisfaction. The team might help create a testing infrastructure that enables the product owner or the feature SMEs to run these tests more efficiently, but the product owner should be the final judge of whether an item meets expectations.

It is important for the product owner to verify acceptance criteria during sprint execution rather than waiting until the sprint review. By doing some testing as the features are completed, the product owner can identify mistakes and misunderstandings that the team can fix before the sprint review. Also, because the team is allowed to demonstrate only completed features at the review, the product owner must ensure that acceptance tests are run prior to the review so that the team knows which features actually meet the definition of done.

Collaborate with the Development Team

The product owner must closely collaborate with the development team on a frequent basis. The product owner is an engaged, committed, everyday role. Many organizations just starting to adopt Scrum fail to foster adequate product owner engagement with the development team, delaying essential feedback and substantially reducing the value of that feedback when it does occur.

This failure to engage can also occur when people new to the product owner role assume that their level of involvement when using Scrum should resemble their involvement during phase-based development. Figure 9.4 compares the typical level of customer- or business-side engagement during a traditional sequential development effort with that expected of a product owner when using Scrum.

Figure 9.4. Comparison of customer or business engagement over time

Using traditional, phase-based development, the pattern of engagement resembles a U-shaped or bathtub-shaped curve. Initially the customers have considerable up-front involvement to help define the complete set of requirements. Once the effort transitions into more technical phases (such as design, coding, and certain types of testing), the customers are “no longer needed.” As such, their level of engagement is quite low or nonexistent during a majority of the effort. In fact, during traditional development, the customers don’t reenter the process until near the very end, when they are required to perform user acceptance testing on what was built. What customers typically discover at this point is that what has been built isn’t exactly what they wanted. To make matters worse, it’s usually too late or too costly for them to make changes—at least in this release. Customers who come in expecting to be delighted instead leave surprised, frustrated, and disappointed. This is when the finger-pointing moves into high gear. The customer claims, “If you guys had read my requirements document more carefully, you would have built what I really wanted,” and the development team retorts, “Well, if you had written your document more clearly, we would have built something different. We built what you asked for!”

Using Scrum, we build a feature at a time, not a phase at a time. This means that we perform all activities to create a particular feature (design, code, integrate, test) during one sprint. Therefore, a constant high level of engagement by the product owner is essential. With such close interaction on short, timeboxed iterations there is far less chance for the product owner and the development team to become disconnected. A secondary benefit is that there is no finger-pointing when doing Scrum well!

Collaborate with the Stakeholders

The product owner is the single voice of the entire stakeholder community, internal and external. Internal stakeholders can include business systems owners, executive management, program management, marketing, and sales. External stakeholders can include customers, users, partners, regulatory bodies, and others. The product owner must work closely with the entire stakeholder community to gather input and synthesize a coherent vision to guide product development.

If the product owner becomes overwhelmed and spreads himself too thin, it will be difficult for him to collaborate with both the development team and the stakeholders at the required level. In some circumstances the workload may be more than one person can reasonably perform, in which case the product owner may enlist the assistance of others to help fulfill the responsibilities of the role. I will address this later when I discuss the concept of a product owner team.

Characteristics/Skills

Figure 9.5 illustrates important characteristics of the product owner role.

Figure 9.5. Product owner characteristics

Although there are numerous characteristics that I look for in a good product owner, they can be grouped into four categories: domain skills, people skills, decision making, and accountability.

Domain Skills

The product owner is a visionary who can synthesize a product vision and lead the team to achieve that vision. Having a vision doesn’t mean that every detail of the vision or the path to achieving the vision is perfectly clear. A good product owner knows that not everything can be anticipated up front and is willing to adapt when change is warranted.

To be effective at vision creation and execution, a product owner must have appropriate business and domain knowledge. It’s difficult to be an effective product owner if you’re new to the product domain. How can you set priorities among competing features if you don’t know the subject matter?

People Skills

A product owner must also be the “voice of the customer,” which requires a good relationship with stakeholders. Because there are frequently multiple stakeholders who could have conflicting needs, the product owner must also be a good negotiator and consensus builder.

The product owner is the linchpin between the stakeholder community and the rest of the Scrum team. In this position, the product owner needs good communication skills to work with both constituencies and to convey information to each group in the appropriate language. A good communicator also exhibits the following qualities: is willing to speak up even if doing so goes against the status quo; confident in his ideas; knowledgeable of the subject matter; able to communicate in a simple, concise, and easily understood way; and credible.

A product owner is also a powerful motivator. When the going gets tough, the product owner can remind people of why they are investing the effort and help people maintain an enthusiastic outlook by reinforcing the business proposition.

Decision Making

The product owner must be empowered to make decisions. A frequent impediment to organizations new to Scrum is that the person selected to be the product owner is not empowered to make any significant decisions. Such a person is not the product owner.

The product owner must also be willing to make the hard decisions—usually by trading off constraints like scope, date, and budget. These decisions must be made in a timely manner and should not be reversed without good reason. In other words, the product owner should be a decisive decision maker.

In making these decisions, a product owner must maintain the proper balance between business needs and technical realities. Although the Scrum team as a whole is responsible when systems accrue unacceptable levels of technical debt, naive product owner decisions and ones that fail to consider system-level effects can frequently be a significant contributing factor.

Accountability

The product owner is held accountable for delivering good business results. This accountability doesn’t absolve other Scrum team members from their own accountability to participate in generating a good return on investment. However, the product owner is on the hook for making sure the resources are being used in an economically sensible way and must accept responsibility if they are not. After all, the product owner has many opportunities along the way to change the product backlog, readjust priorities, or even oversee canceling the development effort entirely.

The product owner must be committed and available to both the stakeholders and the rest of the Scrum team. Being a product owner is a full-time job; to try to do it part-time is a recipe for failure.

Finally, the product owner is a member of the Scrum team and therefore realizes that good economic results are impossible without the collaborative efforts of the full Scrum team. So, the product owner treats the development team and ScrumMaster with respect and trusts that they are partners in delivering the desired results. Together, all Scrum team members should share a Musketeer attitude (I will describe this concept further in Chapter 11). There is no us-versus-them attitude. The product owner, ScrumMaster, and development team are one unit working together toward the same goal.

A Day in the Life

To better appreciate the scope of product owner responsibilities, let’s look at a “day in the life” of a product owner across part of a product development effort (see Figure 9.6).

Figure 9.6. A day in the life of a product owner

During weeks 1 and 2 the product owner is engaged in both portfolio planning (see Chapter 16) and product planning (see Chapter 17). As part of portfolio planning, the product owner might work with the portfolio manager or the governance board to discuss portfolio expectations that could influence the new-product planning. Those discussions provide input to product planning, where the product owner, working with appropriate stakeholders and others, will perform the envisioning of the new product.

At the completion of product planning, the proposed product will be submitted to portfolio planning, where it is subjected to the organization’s economic filter to determine if development will be funded and when work can begin. Figure 9.6 shows all of this occurring immediately after product planning is complete; in many organizations there would likely be a delay between the end of envisioning and when the approval committee or governance board would review and approve funding and work would begin.

In week 3 the product owner is engaged in initial release planning (see Chapter 18). This typically involves a PBI-writing (story-writing) workshop (see Chapter 5 for more details) that includes internal stakeholders, the development team members, and possibly external stakeholders to generate a high-level product backlog that can be used during release planning. The development team members should be available to participate because funding has already been approved. If necessary, a surrogate team can be used if the development team is not yet formed.

Following the PBI-writing workshop, the product owner participates in an estimating workshop (probably a series of meetings over a day or two) during which development team members (or a surrogate team if the actual team has not yet been assigned) estimate the size of high-value product backlog items.

Next, the product owner facilitates an initial release-planning session (longer-term planning). Because some number of product backlog items have already been estimated, the focus of this release-planning activity is on prioritizing the product backlog and balancing the constraints of scope, schedule, and budget (see Chapter 18). The stakeholders are the principal co-participants in this activity; however, some or all of the development team members will need to be involved at some point to identify technical dependencies that could affect the order of the product backlog items.

The goal is to do a sufficient amount of release planning to have an acceptable level of clarity of the overall release, and to provide initial answers to business questions such as what will be delivered and when. For most products this activity should take no more than a day or two to complete. As I will discuss in Chapter 18, release planning is an ongoing activity, so we shouldn’t overinvest at this point by trying to be very precise; we’ll update the release plan as better information becomes available.

Following release planning, the Scrum team performs the first sprint (Figure 9.6 shows a two-week sprint during weeks 4 and 5). At the start of the sprint the product owner oversees the sprint-planning activity (see Chapter 19). During sprint execution (see Chapter 20), the product owner tries to attend the team’s daily scrums; this may not always be possible, but it is a good practice. During the daily scrum, the product owner listens to better understand how the current sprint is progressing and to identify opportunities to assist the development team. Perhaps a team member mentions he is a little fuzzy on the specifics of a product backlog item and needs some clarification before he can complete his current task. If it is a quick clarification, the product owner might offer it up during the daily scrum. If the answer requires anything other than a few-second response, the product owner should say, “I’d be happy to stick around after the daily scrum and discuss it with you.”

The product owner must also be available (typically every day) to answer questions and to test features as they become reviewable. If the product owner knows he can’t be available every day to perform these responsibilities, he must delegate them to an appropriate person so that the development team will not be blocked. I will discuss this idea further later in this chapter.

Also during sprint execution the product owner meets with both the internal and external stakeholders to ensure that priorities for the upcoming sprint are correct and to secure valuable user input that will affect the features chosen for future sprints.

The product owner also performs frequent product backlog grooming, which includes writing new product backlog items and refining existing items, then working with the team to get them estimated, and the stakeholders and team to get them prioritized.

At the end of the sprint, the product owner participates in the two end-of-sprint inspect-and-adapt activities: the sprint review (see Chapter 21) and the sprint retrospective (see Chapter 22). After these are completed, the sprint cycle repeats and the product owner participates in the next sprint-planning activity.

Who Should Be a Product Owner?

Most non-Scrum organizations probably won’t have an existing role labeled “product owner.” So, who within the organization should fill the product owner role?

As I mentioned earlier in this chapter, the product owner needs to face two directions simultaneously: toward the internal and external stakeholders and toward the development team. Thus, the product owner role is a melding of authority and responsibilities that have historically been found in several traditional roles. In its most encompassing expression, a product owner incorporates elements of the roles of product manager, product marketer, project manager (discussed further in Chapter 13), business analyst, and acceptance tester.

Exactly who should be the product owner depends on the type of development effort and the specific organization. Table 9.1 suggests good candidates for the product owner role for different types of development.

Table 9.1. Product Owners for Different Types of Product Development

Internal Development

On an internal development effort, an empowered person from the group that will benefit from the development should be the product owner. For example, if an internal IT group develops a system for the marketing group, an empowered person from the marketing team should be the product owner (see Figure 9.7).

Figure 9.7. Example of a product owner on internal development

Some organizations (typically those that haven’t yet learned the importance of having a business person as the day-to-day engaged product owner) might ask an IT person to handle the day-to-day product owner responsibilities. I will review the issues with this approach when I discuss the concept of a product owner team later in this chapter.

Commercial Development

On a commercial development effort—for example, a company building a product for sale to external customers—the product owner should be an organization employee who acts as the voice of the actual customers. Frequently this person comes from the ranks of product management or product marketing (see Figure 9.8).

Figure 9.8. Example of a product owner on commercial development

Scrum practitioners have hotly debated whether or not the product owner role is really just the Scrum (and agile) renaming of the product manager role. Some believe the two roles are synonymous. Others advocate that the product owner role is larger than the product manager role. And, of course, still others argue that the product manager role is larger. Here’s how I view it.

The areas of product management and product marketing are quite expansive. Pragmatic Marketing, Inc., a well-known and respected company in the product management/marketing field, has created a highly regarded framework that defines the roles and responsibilities for technology product management and product marketing teams (see Figure 9.9).

Figure 9.9. Pragmatic Marketing framework

To cover all of these activities, Pragmatic Marketing suggests that multiple roles are needed, including product strategy champions, technical product managers, and marketing product managers. Most people would agree that if a commercial organization needs to perform all of these activities for a larger product, a team of people is likely necessary.

Is the product owner expected to perform all of these activities? Those who believe the product owner role is a subset of the traditional product manager role argue that a product owner is really just the “technical product manager” and therefore would focus primarily on the small number of activities shown inside the dashed line in Figure 9.9. They believe that because the product owner has to be available to the team on a day-to-day basis, he would not have time to focus on the other activities.

Certainly the product owner is responsible for performing the activities within the dashed line, but I believe that the product owner role is also responsible for more activities. In fact, I believe that the product owner role should be responsible for performing as many of the activities shown in Figure 9.9 as are necessary and practical for the product owner to perform. The extent of that responsibility would depend on the organization, the specific product, and the skills of the person selected to be the product owner. For example, an organization that is producing a simple unit-conversion application for sale in a mobile device app store will not require as many activities as an organization creating the next major release of its enterprise Business Intelligence product. Therefore, it isn’t practical to universally define the extent of the product owner’s responsibility relative to the Pragmatic Marketing framework.

As I will discuss shortly, there are times when the scope of the product owner activities may be too large for any one person to adequately perform. In such cases, we might have a product owner team that includes people who focus on strategy and marketing. However, there will always be a single individual who functions in the product owner role for a Scrum team.

Outsourced Development Project

On an outsourced development effort—for example, company A contracting with company B to build a solution—a representative from company A should be the product owner. Company B may assign an internal person to closely liaise with the product owner, but the product owner should be from the company that is paying for the solution and receiving the benefits (see Figure 9.10).

Figure 9.10. Example of a product owner on outsourced development

The product owner role gets complicated if company A and company B enter into a traditional fixed-price development contract. In that case company B will almost certainly feel that it should be fulfilling most of the product owner responsibilities because it has assumed the risk of a fixed-price contract. In reality, though, company A, as the actual customer, should fill the product owner role. A more appropriate contract would have company A leasing the high-performance development team and ScrumMaster from company B and company A providing the product owner.

Component Development

Last, some organizations might use component teams (see Chapter 12) that build parts of customer solutions but not full customer solutions. These teams tend to create components or other assets that are then reused by other teams to assemble customer-valuable solutions. Because these teams focus at a technical component level, their product owners are typically technically oriented people who are capable of defining and prioritizing the technical features in their backlogs (see Figure 9.11).

Figure 9.11. Example of a product owner on component development

In the figure, there are three business-oriented feature teams that create features that are valuable to the end users. Each feature team has its own product owner focused on that team’s features. Each of these feature teams also leverages the work of a component team that provides them with an asset necessary to complete their features. The component team needs a product owner who can prioritize and oversee the development of the various component-level requests being made by the feature teams. The component team’s product owner is likely to be more technically oriented than the product owners of the feature teams.

Product Owner Combined with Other Roles

If capacity permits, the same person may act as the product owner for more than one Scrum team (see Figure 9.12).

Figure 9.12. Same person as product owner of more than one Scrum team

Usually it is easier for this person to be the product owner of multiple teams on the same development effort, because the work of these teams will most likely be highly interrelated.

Although there are times when the same individual may be the product owner and a member of the development team, it is considered a bad idea for the same person to be both the product owner and the ScrumMaster on the same Scrum team. These two roles counterbalance each other; having one person play both roles creates a conflict of interest that we should try to avoid.

Product Owner Team

Every Scrum team must have a single person who is identified as the product owner and is the only person empowered and accountable for fulfilling the product owner responsibilities for that Scrum team.

Should we allow a team of people to perform the product owner role? If by team we mean a group of people with shared decision making and accountability, definitely not. To properly apply Scrum, we need one individual to be the product owner, making decisions and acting as the single voice of the stakeholder communities to the Scrum team.

That being said, some organizations might form what they call a “product owner team” because they recognize that, in their circumstances, the product owner cannot do the job without a select group of people to provide input and guidance. In other companies, the workload of being a product owner might be greater than any one full-time person can reasonably perform. In those cases, the product owner delegates some product owner responsibilities to other people. Forming a product owner team in either of these circumstances is acceptable as long as there is one person on the team who is the ultimate decision maker and as long as having a product owner team does not degrade into design by committee, with every decision needing approval from eight other people.

Be careful when creating product owner teams. Product owners who are not properly skilled to be the empowered central point of product leadership don’t need a committee—they need a different role. Similarly, product owners who are too busy to fulfill their responsibilities might not need a team. Perhaps the real problem is that the organization has chosen to start too many development efforts at one time, or there are just too few product owners to cover the necessary products.

Alternatively, perhaps the product we are building is just too large and should be broken into a series of smaller pieces with more frequent releases. With small pieces a single person might more easily fill the product owner role. Also, if we have structured our teams poorly (see Chapter 12), or poorly conceived the product backlog structures (see Chapter 6), a single product owner might find it difficult to do his job. Be sure that your product owner teams are truly necessary and not just masking an underlying problem; otherwise, the situation will become more complicated and jeopardize your overall outcome.

Product Owner Proxy

As I mentioned earlier, some companies doing internal development ask an IT person (for example, a business analyst or development manager) to be the product owner because the business unit person is too busy with other work. Because everyone knows that the IT person is really not empowered to make important final decisions (one of the key responsibilities of any product owner), organizations that do this have filled the product owner role ineffectively and confusingly. A better solution is to free up enough of the business unit person’s time to be the true product owner but have the IT person act as the product owner proxy in certain interactions with the team.

A product owner proxy is a person enlisted by the product owner to act on his behalf in particular situations. Everyone on the Scrum team knows that the proxy is not the actual product owner, but everyone also knows that the product owner has empowered the proxy to make at least some tactical decisions on his behalf. A common example is when the product owner spends a great deal of time meeting with customers and users to make sure he has his fingers on the pulse of the marketplace. This person is reliably unavailable to the development team on a day-to-day basis. In this case, the product owner might enlist the support of a proxy to handle the day-to-day interaction with the development team regarding product backlog items.

For this approach to work, it is essential that the product owner actually empower the proxy to make decisions and not unreasonably overrule those decisions in a way that would undermine the proxy’s credibility with the team. Remember, even though the product owner can empower others to assist him, he cannot delegate the ultimate responsibility for ensuring that the work gets done—he is still on the hook for that.

Chief Product Owner

Another situation where a product owner team is frequently created is on very large products. Earlier I noted that a single person might be the product owner for a couple of Scrum teams, but what about scenarios that involve many teams? For example, I trained and coached an organization that had a development effort that involved upward of 2,500 people. With an average team size of fewer than 10 people, the organization had more than 250 teams on the effort. One person can’t be the product owner for 250 teams. In fact, one person can’t be the engaged, day-to-day product owner for more than a few teams. In cases like these, the product owner role needs to scale hierarchically as shown in Figure 9.13.

Figure 9.13. Hierarchical product owner role

Ultimately in Figure 9.13 the person labeled chief product owner is the product owner for the whole product. However, the chief product owner has a team of product owners to ensure that the product owner role is filled correctly at each lower level in the hierarchy. If you choose to use this approach, ensure that the individual team product owners remain empowered to make the vast majority of the decisions at their levels, rather than having to pass such decisions up the hierarchy to be made at higher levels.

Closing

In this chapter I expanded the description of the product owner role. I emphasized this role as the empowered central point of product leadership and described important responsibilities and characteristics of the role. I then described what the product owner does during the various Scrum activities on a project. I went on to discuss what type of person should fill the role for different project types. Then I described how a single person might be the product owner for more than one Scrum team, and how on occasion a single person might be both a product owner and a team member on the same Scrum team. I ended by discussing the idea of a product owner team with a focus on product owner proxies and chief product owners. In the next chapter I will discuss the ScrumMaster role.