“It takes a village to raise a child,” claims the old Nigerian proverb. That’s a far cry from “A mother is the single, wringable neck responsible for turning out a good kid.”
The folks at Yahoo! coined the phrase “single, wringable neck” to emphasize that every software delivery team needs to be guided by decisiveness, responsibility, and accountability.
Scrum emphasizes the importance of the product owner role, because the business—rather than engineering—should define how the business will derive value from software.
In the original Scrum book , Ken Schwaber and Mike Beedle describe a Scrum team as including a product owner—a single person who owns the vision and backlog, accepts completed work from the team, and calls for releases.
Yet, in dozens of companies I’ve visited—those that are agile and those that are striving toward agility—the single, accountable product owner is not enough to define value for their software projects and products. The one-product owner/one-team model just doesn’t cut it for larger organizations.
Different companies have different needs in terms of how to define value for their software, who does that work, and by what processes. For example, some companies struggle with scale—how can I staff every Scrum team and also watch the big picture? Some companies seek a solution that addresses complexity, such as a product of tightly integrated components or one that requires the input of many specialties. Other companies adopt a Scrum framework only to have it make visible an under-investment in product management; they need to find people with the right skills to support delivery teams.
My challenge has been to help these teams find a structure that meets their needs while also following the principles of agile software development—that is, a structure that emphasizes collaboration and that focuses development squarely on providing value with quality.
In all the permutations I’ve encountered, I’ve discovered patterns used by companies to fill the product owner role successfully. Each pattern addresses different challenges regarding scale, complexity, or skill sets.
A common situation is the case of one product owner who owns a single backlog for a single product (or project) that is being worked by two teams. It’s usually a simple case of the work’s needing two teams to meet delivery goals.
Although this scenario breaks with the idea of one owner per team, it does have the advantage of providing the product with a single owner. Thus, that owner has the vision and owns the entire backlog. Depending on the skills of the teams, she may have maximum flexibility to move work between teams to deliver value.
If the owner is new to agile software development, I recommend you ease her into this arrangement. Let a newly minted product owner learn the rhythms and cadences of iterative development in a Scrum 101 arrangement before you ask her to support two teams at once.
That said, this scenario can be successful as long as that one product owner is truly dedicated. There’s no time here for her to be assigned to any other work. Her time will be filled with grooming enough backlog for two teams’ worth of work each iteration (see sidebar: Grooming the Backlog) and with accepting done work.
And, therein lies the challenge. That’s a lot of work, especially if the product owner has to spend much time with stakeholders to groom the backlog effectively. The Scrum 101x2 product owner may fall behind—and burnout—quickly.
Instead, try ...
Or, you could call it “Scaling Scrum 101.”
In this pattern, we assign a product owner to each team, just as the authors of Scrum originally recommended. This means each team gets maximum access for collaborative planning, prototype reviews, questions during the iteration, and story acceptance. This highly collaborative work and intense involvement of the product owner ensures common vision and completed stories that more often deliver value.
If we’re describing two teams working on a single product or on closely related work, the challenge is for the two teams and two product owners to coordinate and collaborate effectively. Scrum doesn’t specifically prescribe ways for these product owners to collaborate the way it helps a delivery team know how to collaborate via daily stand-ups and planning sessions.
In my experience, product owners need formal, cyclical opportunities to collaborate on backlog grooming, planning, and feedback.
For the teams, the more closely connected the work, the more important it is for them to conduct some kind of release planning (plan the work that will go into the next release) or midrange planning (plan the next three to six iterations, regardless of whether they result in one release or many). That planning session is the opportunity to coordinate feature delivery and identify and mitigate dependencies. At this level of planning, we are talking about backlog items across iterations, not detailed tasks within an iteration. The idea is to determine at a midlevel which work will be done when.
In addition, the product owners must meet periodically to ensure their backlogs remain in sync. If the work is more separate, they can meet relatively infrequently, perhaps once an iteration. If the work requires more coordination, then they need more frequent meetings. I’ve known at least one group of product owners who met daily.
The product owners and their teams should also attend each other’s demos to get a good sense of each team’s progress. Finally, I recommend a specific release or midrange retrospective that is focused not on individual teams but on how the multiple teams and product owners are coordinating.
In this scenario of multiple related teams, each with a product owner, the biggest pitfall I’ve seen is a failure to build consensus on a single direction for the software. In that case, the group might benefit from an über product owner.
The Product Manager, aka Über Product Owner
The problem of clear, big-picture vision can be solved by the über product owner pattern. In this scenario, a so-called über product owner (often someone with the title product manager) “owns” the overall value of the product or project and is assisted in execution by team-level product owners (often people with business analyst titles).
The über product owner owns the big picture and the release and ensures related teams are coordinating to a shared vision and definition of value. The team-level product owners then own the backlogs and must help detail user stories with acceptance criteria that will help build toward the release goals.
The key to success in this model is that the über product owner and product owners work very closely to ensure they are working toward the same goals. For example, I worked with at least one company in which the über product owner had weekly meetings with his team-level product owners. This ensured that the product owners had an opportunity to voice any concerns or discuss any obstacles. Another purpose of the meetings was to synchronize the future backlog, to ensure all backlog items were prioritized to meet release goals.
I worked with another group of product owners who met with their über product owner in a daily stand-up. The idea was to report on progress in backlog grooming and make visible any impediments to getting clarity on upcoming backlog items.
I have seen the über product owner approach fail when the person in the role of über product owner did not really understand the evolutionary, iterative, and value-oriented nature of agile software development. For example, in one company, the über product owner expected to be involved up front and again just before release but did not expect or want to weigh in on feedback and direction throughout the development cycle.
In another example, the product owners were trained in agile but were led by an über product owner who was not trained. That über product owner measured progress according to his original sense of the complete scope of the project. He did not understand that, instead, he and his product owners should constantly evaluate the delivered features to determine what the minimal marketable feature set might be. As a result, his product owners felt pressured to deliver everything by the original date, regardless of new learnings. In that disconnect, the über product owner offered more pressure than direction. Thus, it is critical that the über product owner be as versed in agile software principles as anyone.
In this work of tradeoffs, the agile product owner—über or otherwise—can be helped by an architect partner.
A colleague of mine worked at a consulting company that was building Web sites for clients (and also building common code). The product owner role was filled by a business analyst/architect tandem from the client. This tandem served a user community and also a technical steering committee. Together, they were able to ensure that the work of the software development teams served both user goals and technical goals.
For companies that use an architect role (see sidebar: The Role of the Architect), it’s critical that product owners have a close working relationship with architects. Luke Hohmann of Enthiosys describes agile product roadmaps as containing an architectural element. Just as we need to plan a product direction strategically, we want to think strategically about evolving the system to support that plan. Dean Leffingwell talks about laying architectural runway that serves the product direction.  These efforts will be most successful when product owner and architect are collaborating, rather than competing.
Whether a true tandem or simply a productive partnership, the dynamic duo of product owner and architect is ultimately working to serve its core constituencies: users and customers. Yet how does a product owner—or über product owner—make sure she really is representing all those constituents? Enter the product council.
Another village that might support a product owner is the product council that helps define priorities at the project, or epic, level.
I was product owner for an internal enterprise application that served nearly every company department. Each department had its own wish list of enhancements and defect fixes for that application. Some projects crossed departments. My product council (actually called an IT steering committee) met once an iteration. At those meetings, department heads lobbied for their projects and the chief operating officer provided information about company-level strategies. I guided the group to reach consensus about project priorities and the group provided a ranked list of projects. Note that projects in this case were anywhere from three iterations to less than one iteration.
The product council did not determine which stories took priority within a project. I worked with the department heads and stakeholders to determine which stories of a given project would make the cut for a given iteration.
The challenge in my case was gaining consensus among people who were competing for limited resources. The key was strong facilitation and the payoff was that decisions were stickier—department heads stopped trying to go around the system to get their work prioritized in the queue.
The added bonus was that the department heads stopped asking IT to make trade-offs between projects. Instead, they did their own negotiation to descope projects and intertwine priorities. I started hearing sentences like “What if we do the highest-value part of your project in two iterations, then deliver the highest-value part of mine?”
Years ago at Rally when we started with Scrum, we used to do a design meeting every few weeks with a couple of key stakeholders to talk about what was coming up and prepare the backlog. This worked relatively well, but as we added more discipline to our release cycle, the ad hoc backlog planning to which our product owners were accustomed started to break.
We found that if you want your team to be able to make a commitment around eight weeks of backlog, you need to do somewhat more preparation. And, if you want your team to meet that commitment, you need a mechanism to manage your stakeholders to minimize backlog churn.
About a year ago, Rally chartered a product council to solve this problem. The product council is led by the product line manager (über product owner) for each product and consists of stakeholder representatives from all interested departments. This group operates as a lightweight Scrum team that grooms the backlog for the next release, meeting every two weeks and working through a sort of kanban of features, as shown in figure 1.
Product Council Kanban
The advantage to our product owners is clear guidance for the product, which includes many viewpoints. The council helps right-size our investment on research, leading, we hope, to the biggest bang for our buck as product owners look ahead.
But what if there are many constituents who need to be involved in more than an advisory role? What if you really need the input of many stakeholders at a detailed level throughout every iteration? Enter the product owner team.
The Product Owner Team
I introduce this last pattern with some trepidation. I think the product owner team pattern is fraught with challenges around coordination and collaboration. That said, I’ve seen it often enough—and seen it be successful enough—that I believe it’s a valid pattern with benefits for certain organizations.
The basic pattern is that of having a group of people speak with the single voice of a product owner.
I worked with one company that developed medical practice software. When the company first started with agile, it had seventeen different job titles on the project, which felt, at least to some developers, like an anti-agile level of complexity and specialization.
Some of this complexity was truly unavoidable. Medicine is already a complex, specialized area, and the company had clinical sub-specialties to serve. It further had the complicated relationships of the very hierarchical world of medicine, where physicians of different specialties, nurses, and practice staff all have clear places and real and different passions. On top of all that, the project included user experience designers who worked on a strategic level, business systems analysts who had expertise around the business, a product management group, and business analysts who were requirements analysts.
To handle all that specialization while managing a single product backlog, the company formed a product owner team. Here’s a true village raising the child—“software that delivers value.” The product owner at the head of it all was a practicing physician who drove feature prioritization. Business analysts and clinical analysts would then “plead their case” to the product owner to get detailed stories prioritized. Challenges around this effort included a lack of knowledge on how to “sell” ideas, although that got fixed pretty quickly once stories got deferred. It worked well in terms of communicating value and context to delivery teams, since stories had to be well thought out in order to rise to the top. Technically, the product owner also had to accept stories, although he usually deferred to the analysts.
This team of owners worked like a Scrum team to evolve a ranked backlog. The owners committed to iterations for which the deliverable was a story ready for the delivery team to estimate and plan.
To provide some consistency, each of the business analysts on the product team was also assigned to a delivery team. The clinical analysts and business systems analysts would “follow” their stories to the delivery team that was going to implement them, once that was determined in sprint planning.
Thus, this group managed specialization while also providing the consistency that the delivery team needed.
A variation on the product owner team solves the problem not of specialization but of silos. At the Agile 2008 conference, British Telecom (BT) presented its solution to the product owner puzzle. A value stream mapping by Mary and Tom Poppendieck had identified incredible waste in BT’s highly siloed organization.
In the wake of that assessment, BT sought to coordinate delivery among the silos and create end-to-end ownership by creating a product owner team of senior managers. The product owner team members had to be dedicated to the project, and they measured success or failure only as a team—quite a departure from their segmented history.
All decisions regarding backlog, prioritization, and acceptance were made collaboratively and by consensus. A key to success, BT reports, was a strong facilitator who could guide these senior managers to decisions.
What Village Can Guide Your Software Development?
As you try to determine how to fill the product owner role for your organization, worry less about the form or about what the literature says, and focus instead on how to fulfill the principles underlying the role:
Adopting agile practices may look like a software development decision, but in the end, the biggest change is often for the product management or business analyst community. We need to set up this group for success with the same level of support and guidance as we do delivery teams. Too many organizations see one owner per team and balk at the impossibility of it. Instead, consider which one of these patterns reflects your organization and can provide the business direction that ensures your development organization delivers value.