In my
last post, I described the product owner as the person in charge of the product and the project. For products of modest complexity and small projects, it may be feasible to have one individual playing the product owner role. But how do we deal with product ownership on large Scrum projects that develop complex products? How can one person collaborate with 100 or more people? Before I share my recommendations, let me state a general warning: Avoid large projects whenever you can. Start small and quickly develop a product with the minimum functionality. If you have to employ a large project, scale slowly and grow the project organically by adding one team at a time. Starting with too many people causes products to be overly complex, making future product updates time-consuming and expensive. (This insight is captured by
Conway’s Law.)
A large Scrum project consists of many small teams. Instead of enlarging a team, we tend to split it into two and add new people to the newly formed teams. Now each team needs a product owner, but one product owner can look after only a limited number of teams. How many teams a single product owner can support without being overworked or neglecting some responsibilities depends on a number of factors, including the product’s newness, its complexity, and the domain knowledge of the teams. My experience suggests that a product owner usually cannot look after more than two teams in a sustainable manner. Consequently, when more than two teams are required, several product owners have to collaborate. This puts us in a dilemma: “The Product Owner is one person,” write Ken Schwaber and Mike Beedle write in Agile Software Development with Scrum (2002, 34), but a large project requires several product owners! The solution is to put one person in charge of the product. This introduces a hierarchy of collaborating product owners with a chief product owner at the top.
The chief product owner guides the other product owners. The individual ensures that needs and requirements are consistently communicated to the various teams, and that the project-wide progress is optimized. This includes facilitating collaborative decision making as well as having the final say if no consensus can be reached. If the project grows organically by starting off with one team, the very first product owner typically becomes the chief product owner.
Product owner hierarchies vary from a small team of product owners with a chief product owner to a complex structure with several levels of collaborating product owners. Let’s have a look at the two options, starting with the simpler one.
A simple product owner hierarchy
The project organization in the picture above consists of three teams and three product owners. Each product owner looks after one team. The product owners form a product owner team with product owner B acting as the chief product owner. Even though there is a chief product owner, the product owner hierarchy is flat.
The following figure shows another option suitable for larger Scrum projects, which is based on Ken Schwaber’s book The Enterprise and Scrum.
A complex product owner hierarchy
The project organization partially depicted in the figure above consists of four layers and nine product owners. Each product owner guides and assists lower-level colleagues. The top-level product owner is the chief product owner in charge of the entire development effort and is responsible for the product’s success. The product owners now form a rather extensive hierarchy.
Note that a complex product owner hierarchy introduces a certain specialization of the individual product owner jobs. The chief product owner leads the overall development effort, coordinating with customers and other stakeholders, and may help to prepare the product launch. The lower-level product owners are more focused on their features or subsystems and work closely with the development teams. Ken Schwaber writes in The Enterprise and Scrum (2007, 72):
The Product Owner plans, composes, distributes, and tracks work from his or her level down…. The higher the level is, the harder the Product Owner’s … job is. The responsibility of Product-level jobs usually requires someone with Vice President-level or Director-level title and authority.
RSS
The Product Owner *can* be a consortium…
… In his new blog post Roman Pichler breaks with the supposedly golden rule that a Product Owner must be a single person ……
Roman
Would you recommend any formal tools or practices for effectively scaling the product owner? For example a clear, documented product vision with cascading goals or a product owner daily scrum?
Geoff
Hi Geoff, A shared product vision is certainly particularly important on a large Scrum project to help everyone move in the same direction. I also recommend using one product backlog, as the product owners and teams collaborate to create or update one product. To succeed with a large-scale development effort, specific practices have to be applied. These include extending the product backlog grooming horizon to two to three sprints, employing lookahead planning to anticipate and resolve dependencies between the teams, running Scrums of Scrums to facilitate the communication between the teams, and enabling joint sprint reviews and retrospectives to foster a sense of unity and project-wide learning. Regarding the project organisation, I favour feature teams over component teams. (The former implement a theme or set of user stories; the latter build a subsystem or component.) With feature teams, the product owners are responsible for pieces of functionality such as “Entertainment” or “Chess” with the chief product owner looking after the entire product.
[...] decision making, including product backlog prioritization and release planning as my post “Scaling the Product Owner” [...]
Hi Roman,
I agree completely with all you’re saying. This is exactly how we’ve scaled the role of the product owner in several large projects. I have only one remark – I would only cautiously suggest 1 product owner can support up to 2 feature teams, because of one of the common product owner mistakes which is the risk of the overworked product owner. (see: http://www.romanpichler.com/blog/2010/02/avoiding-common-product-owner-mistake/)
Jutta
[...] the product owner role Scaling the product owner Avoiding common product owner mistakes Desirable characteristics of a product owner Product owner = [...]
[...] from delegation (but also negative in situations that have been unclear). See for example Roman Pichler’s advice on Scaling the Product Owner. Sometimes I believe that a split into business-facing and team-facing Product Owners is another [...]