The Chief Product Owner on Large Agile Projects
The Chief Product Owner on Large Agile Projects
An Agile thought leader discusses how Agile teams and product owners can scale up, and what the PO role looks like while working in a scaled Agile team.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
A Note on the Term “Chief Product Owner”
The labels “chief product owner” and “product line owner” are the ones I generally favor, but they are representative only; use others if you wish. In addition to these, I’ve seen both program owner, super product owner, area owner, and feature owner used successfully.
For consistency with the bulk of existing Scrum literature, I prefer to use “product owner” for the individual who works directly with one or two teams, prioritizing their work and doing all of the other things associated with the product owner role. In these multilayer hierarchies, the product owner is often someone whose business card reads: “Business Analyst.”
The product owner role can be one of the most challenging on a Scrum project.
On all projects, the product owner is torn between competing inward-facing and outward-facing needs. Among the inward-facing tasks are participating in planning meetings, Sprint Reviews, Sprint Retrospectives, and Daily Scrums; managing the product backlog; answering questions from the team; simply being available to the team during the Sprint.
A product owner’s outward-facing tasks include talking to users about their needs; creating and interpreting user surveys; traveling to customer sites; attending industry trade shows; managing stakeholder expectations; prioritizing the product backlog; determining product pricing; developing a medium- and long-term product strategy; watching for industry and market trends; performing competitive analysis; and more.
Too Much for One Person to Do
On a project with one team of developers, this can be a vast but achievable amount of work. On a large project with multiple teams, however, the product owner role is too big for one person, so we must find ways of scaling it.
As a project grows to include multiple teams, ideally a new product owner is found for each. If you cannot achieve a one-to-one correspondence between teams and product owners, try to have each product owner responsible for no more than two teams. This is usually the most that one product owner can effectively work with.
At some point, as the overall size of the project grows, it makes sense to introduce a hierarchy of collaborating product owners. The figure below shows such a hierarchy, with a product owner working with each team, two product line owners each working with a cluster of teams and a chief product owner. Naturally, layers can be added or removed as needed for the scale of the project.
Sharing Responsibility, Dividing Functionality
A chief product owner is responsible for having an overall vision of the entire product or product suite. The chief product owner conveys this to the entire team in whole-team meetings, e-mails, team get-togethers, and through whatever other means are available.
But the chief product owner is almost certainly too busy to assume hands-on responsibility for working as the actual product owner for one of the five- to nine-person teams building the product. At this level, the external-facing requirements of the role are too great.
A good chief product owner will be very involved with teams—attending Daily Scrums occasionally, walking through team areas whenever in the office, and offering support and feedback. But the chief product owner will need to rely on the product line owners and product owners to handle the intricate details of their product segments within the overall project vision.
An Example of a Chief Product Owner and Product Line Owner
Suppose, for example, we decide to develop an office productivity suite that will include a word processor, spreadsheet, presentation software, and personal database. Competing with Microsoft Office, Google Apps, and other products will be daunting, but our chief product owner is fearless.
Because the chief product owner will be focused on strategic issues, competitive positioning and such, product line owners are selected to own the individual products in the suite—the word processor, spreadsheet, presentation program, and database.
Each product line owner, in turn, identifies product owners who will be responsible for feature areas within the product. The product line owner for the word processor, for example, may work with one product owner who is responsible for tables, another responsible for stylesheets and printing, another who is responsible for the spell checker, and so on.
Although as previously mentioned, the chief product owner is too busy to be the product owner for one team, it is possible for a chief product owner to act as the product line owner for part of the product.
Continuing with the preceding example, our chief product owner may choose to also be the product line owner responsible for the word processor, perhaps because of being in that role previously.
Similarly, a product line owner will often want to stay involved in a more hands-on manner and will also work as one of the product owners. Perhaps our product line owner for the spreadsheet product also acts as the product owner for the team that will add charts to the spreadsheet product.
Although functionality can be divided along these lines, it is important for all product owners to feel a shared responsibility for the full product. They must also instill this feeling of shared responsibility in the teams they work with.
How Do You Scale Up the Product Owner Role?
How do you handle the product owner role on projects with three or more teams? Please share your thoughts in the comments below.
Published at DZone with permission of Mike Cohn . See the original article here.
Opinions expressed by DZone contributors are their own.