Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed teams and iterations. To see the full series, select the “Big Picture” blog post category.
In this post, we’ll describe the Agile Product Owner [callout (3)].
One of the nice things about blogs is that the usage statistics show where peoples interests (at least those who read your blog) lie. In this blog, there is typically a high degree of interest in the Product Owner and Product Manager posts and they appear as the most frequent search terms as well. So as I endeavor to put my summary thoughts down here, I promise myself to return to this topic for some future, more in-depth, posts on this critical topic. For my other current posts on this topic, check here.
For now, however, since this series is about the Big Picture and the Product Owner is just one element, we’ll have to be content with the highlights. Relative to the Big Picture, I’ll describe three facets of the product owner role here- responsibilities, attributes and organization.
Manage the Iteration Backlog – The primary responsibility of the product owner is the development and maintenance of the iteration backlog. The iteration backlog is the repository for all user stories that are currently envisioned to address the user’s needs. The Product Owner owns this key artifact. That means they can add, delete or update as necessary to control the scope and content of the implementation. At the end of each iteration, the product owner reprioritizes the backlog for the next iteration and this continues for as long as the product (or application) serves its marketplace. (The iteration backlog itself is the topic of the next post).
Own the Iteration – In the Big Picture graphic, the Product Owner is located next to the iteration backlog. This illustrates the “near total immersion” of the product owner in the day-by-day, week-by-week delivery of core functionality via iterations. In addition, the product owner is typically the customer and Q/A proxy at iteration demos and is empowered to accept individual stories and the iteration as whole. So the product owner owns the iteration.
Collaborate with Product Management– As implied in the Big Picture, the strategic direction for the product line is typically driven by the enterprises Product Managers, who are aligned most closely with the customers and the market. So in addition to the team-based responsibilities, the Product Owner engages in a continuous collaboration with the Product Managers, determining priorities and tradeoffs. In many organizations this creates a “bold dotted line” of management reporting and this larger team steers the enterprise to its destination. In other organizations, the Product Owners are the Product Managers or report into the same organization. (see below).
Attributes of the Product Owner
Ability to communicate– the product owner is the glue chip that seamlessly binds the product management function and the development team. Doing so requires the best possible communication skills as the product owner translates, via the user story metaphor, user and business objectives into the technical terms the teams understand. Moreover, the product owner will almost certainly be involved in customer demos, sales support and the like, so a bit of polish and some customer friendly skills go a long way to enhanced performance in this role.
Technical Skills – effective scope triage requires the constant evaluation of technical, functional, performance and user-value tradeoffs. This in turn, requires a reasonable degree of technical competence as the language of discussion and the foundation for effective decision making is driven by the technology of the implementation. In addition, continuous refactoring is integral to agile, and since the product owner owns the backlog, prioritizing refactors vs. value stories is a critical skill that requires a technical foundation.
Trust – in many enterprises, the product owner is a new role, as the company discovers that the high velocity of elaboration and the need to be bound to the team for story and iteration acceptance outstrips the product management organization’s ability to keep up. Given the nature of this pivotal role, most agile enterprises end up promoting people from the development teams to fulfill this role. Since the primary responsibility for prioritizing and managing the backlog (i.e. what will and will not be done) falls to this role, the most essential quality is trust. The teams have to trust the product owner to make the hard calls on scope triage and to defend their interest in quality and functionality; the product managers have to trust the product owner to faithfully represent their feature priorities to the team.
This one is easy. In order the prevent the organizational schism (read: dysfunction) that can be so easily created in translating market requirements into technical requirements and, even more importantly, to assure that the accountability for timely delivery rests with the team, the primary “binding” of the product owner in the organization is to the development team. This means that the APO should be 1) collocated with the team and 2) held to the same performance measures as the team. In most enterprises that mean that the product owners also 3) reports into the same line management as the team. However, in my experience 1) and 2) are mandatory, 3) is only convenient. In any case, I intend to leave no ambiguity to my opinion that the agile product owner is part of the development team.
In the next post, we’ll discuss the Iteration Backlog in more detail.