Part II- Responsibilities of the Agile Product Owner in the Enterprise

Note: This is a part two of a three part series on the critical Product Owner's role within the agile software enterprise. In Part I, On Agile Product Managers and Product Owners: A Scalable, Nuanced Approach , I described why enterprises need to adopt a dual approach to this role; one which empowers both agile Product Managers AND agile Product Owners to drive the enterprise to its objectives. In this part I'll provide some specific guidance for the responsibilities and activities of the Product Owner in this larger and much more challenging, enterprise context. In an upcoming Part III, Seeding the Product Owner Role in the Agile Enterprise, I'll provide some case study "vignettes", which illustrate how some real, agile enterprises found the people necessary to fill this role, along with some of the unique challenges they faced and the solutions they applied.

Summary of Part I - On Agile Product Managers and Product Owners: A Scalable, Nuanced Approach
In Part I, I described why, in the enterprise, the responsibilities of the agile Product Owner, (as primarily defined by Scrum), is really a set of responsibilities that are shared between a significant number of agile Product Owners and a smaller number of agile Product Managers.

Table 1 - Responsibilities of the Agile Product Manager and Agile Product Owner in the Enterprise

This conclusion isn't particularly startling when you look at some basic enterprise facts:

1) It can take a substantial number of agile teams (5-10 or more) to deliver significant end user value, for even a single new feature in a large application.

2) It can take an even larger number of teams (20-100 or more) to deliver a release to the market.

So with respect to Owning the Vision (Feature Backlog), you obviously can't have 5-10 Product Owners each trying to deliver their individual view of the vision of the feature to the market. Therefore the overall vision for the feature must rest in the hands of someone who has the skills, knowledge and capacity to work with customers to define and validate the feature vision. In most software vendors, this typically rests in the hands of the Product Manager. (In the IT shop, this role is often fulfilled by a Business Owner or project manager).

With respect to Owning the Release, the problem is compounded because it takes the collaborative efforts of 20-100 agile project teams to deliver a release. Each Product Owner contributes their feature; sub-feature or component, but the release itself must be under the vision and governance of a larger authority, i.e. the Product Managers/Business owners working, in turn, with those who have responsibility for the portfolio.

Ability to communicate- the Product Owner is the "glue chip "that binds the Product Management function to the development team. Doing so requires good communication skills as the Product Owner translates user and business objectives into the level of detail suitable for implementation. Moreover, the Product Owner will almost certainly be involved in customer demos, sales support and the like, so some customer skills are beneficial.

Good business sense-Agile's insane focus on value delivery also demands that Product Owners should have working knowledge of the business domain. In this way, the PO can better understand and define user stories that deliver real value to the end users and establish priorities and appropriate tradeoffs for system functionality and performance. If that is not practical, the PO must at least be inclined towards the user and business domain.

Technical foundation - effective scope triage requires the constant evaluation of technical, functional, performance and user-value tradeoffs. This, in turn, requires a degree of technical competence as the foundation for effective decision making is based on the technology. In addition, as continuous refactoring is integral to agile, prioritizing refactorings and defects vs. new value stories is a critical skill.

Trust -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 attribute of the Product Owner 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 teams.

Driving the iteration

• Co-Planning the release
• Collaborating with Product Management

I'll describe each of these in the sections below.

• A short statement of the draft objective of the iteration.
• Coordination of common objectives and dependencies with other Product Owners/Product Managers.
• Review and reprioritize the backlog. This includes stories that (a) were already in the backlog; (b) failed acceptance in the current iteration; (c) are generated from defects or bugs.
• Consider necessary refactorings,, defects, constraints, and dependencies.
• Understand the team's velocity for the upcoming iteration.

• The team discusses each item until it is well enough understood for the development team to detail and estimate engineering tasks.
• This process is repeated for each story on the backlog until the team runs out of capacity.

The development team then presents its estimates to the Product Owner. Rarely, however, do the team's estimates and velocity match the Product Owner's initial objectives. (After all, what self- respecting Product Owner would have such limited vision that they might under-commit the team?) Therefore, the final, agreed-to scope of the iteration is the result of some negotiation between the Product Owner and the development team.

• A committed iteration objective.
• A prioritized list of stories with estimated tasks and owners.

In any case, however, the Product Owner helps positions the development team for success in the iteration. For if they fail, they fail together.

• Define - elaborate the story and its acceptance test.
• Build - build the code and the test.
• Test - Get the code to pass the test and ready for final acceptance

This cycle repeats within iteration until the end of the time box, with an objective of getting all stories completed and accepted.

While the primary responsibility for landing the iteration rests with the team, the Product Owner has a critical, daily role as well:

• Work with developers and testers to elaborate each story.
• Re-scope where necessary.
• Attend the daily stand-ups.
• Review stories that are ready for acceptance.
• Accept those stories that pass the acceptance criteria.

• Presentation of each story by the responsible party.
• Discussion and feedback with stakeholders.
• Product Owners move the story to "accepted state"or leave the story in the backlog if incomplete.

At the end of the review process, the Product Owner reviews the objectives of the iteration and decides whether to accept or not the iteration based on how well the team (inclusive of the Product Owner) did against the stated objectives. The final activity is the retrospective, where the team takes the time to reflect and assess on the results and then adapt the development process accordingly.

"we failed to deliver these stories that weren't understood before we accepted it."

Therefore, one of the most important Product Owner activities is just-in-time elaboration of those stories that are about to reach an iteration boundary.

To this end, the Product Owner always has a backlog stories that need additional elaboration via research, use-case development, prototyping or whatever to assure that they are sufficiently defined just-in-time-prior to the iteration boundary. These well-elaborated stories can be better estimated, accepted into the iteration, and most importantly, delivered.

Iteration Preview Meeting
A structured way to address this problem is via an in iteration preview meeting, wherein the Product Owner discusses stories that are anticipated for upcoming iterations. This gives developers a a break from the "tyranny of the urgent iteration" and a chance to think about future work. Also, a better understanding of future stories gives the developers the ability to implement existing stories in a more synergistic way.

A Product Owner's Iteration Calendar
Taken together, the activities and meeting commitments can fill up a Product Owner's daily diary pretty well, as the figure below indicates.

Figure 3 - The Objective is to "Release"

Release Planning is the seminal enterprise event that regularly aligns the teams to a common vision and release objective and the Product Owner plays an active role. I've written about the Release Planning event extensively in my blog [2] and I won't belabor it here. . Prior to the event, the Product Owner will typically:

• Update the team's local backlog.
• Meet with other Product Owners to understand overall system status.
• Meet with Product Managers to understand the vision for the upcoming release.
• Brief the team on the upcoming release objectives.

During the event, the Product Owner will typically:

• Help identify, prioritize and estimate stories that will be necessary to achieve the release objectives.
• Help design the release plan by laying the stories into iterations.
• Participate in the team's discussion, impediment and risk identification.
• Identify and coordinate dependencies to ensure a cohesive solution
• Participate in refining the release objectives and making a commitment to the release.

Figure 4 - "Fat Dotted Reporting line" to Product Management

line to product management" as Figure 4 shows.

From a line management perspective, Product Owners typically report into development. They:

• Are collocated with the team.
• Are rewarded, etc. based on how the team as a whole performs.

But they are also honorary members of the product management organization, where they :

• Receive overall product direction.
• Attend most relevant PM meetings, functions, and planning sessions.
• Receive input with respect to career growth and performance.

In this way, the enterprise has an extended steering wheel-from the portfolio-to the product management organization-to the project teams. Of course, making this work fairly seamlessly creates its own set of challenges.

In her Agile Product Owner blog [3], Jennifer Fawcett often reflects on the nature of these roles within the enterprise. She also notes the challenge in creating a highly effective working team. Recently, she commented on the agile Product Manager (APM) and agile Product Owner (APO) topic:

"Creating the Ultimate Product Team does not come without emotional challenges of adopting, coaching, and nurturing this high-performing team. Past processes, roles, and behaviors do not change overnight"

She goes on to provide tips for building Collaboration, Partnership and Trust as the essential ingredients for building the ultimate APM/APO team.

"Collaboration - Create an iteration cadence that supports daily collaboration. Allow for all meetings on the engineering cadence to be "open door". If Product Management cannot attend, Product Owners should summarize high-points in an email or minutes.

Partnership - Partnership between APMs and APOs is requisite. Ask your Product Managers; "How can I help?" For the most part, Product Managers are more than willing to take you up on it. Meet after stand-ups for a few moments to see if anything needs attention. Synchronize and communicate the ever-changing corporate priorities daily.

Trust - The foundation of building your ultimate team is to trust your colleagues and APM/APO partners to make the right decision. Be forewarned, that your APM/APO partner will sometimes make a decision that is opposite of yours. Support each other's decisions, so that teams know you are both empowered, and can be trusted with business decisions and authority."

Of course, we've also discovered that in the enterprise setting a significant number of talented people may be required to fill the new Product Owner roles. In Part III, the next and final installment, I'll describe some real world examples of how and where enterprises found the right people to fill this role, as well as some of the challenges they faced.

Bibliography
Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. New York: Addison Wesley Professional, 2007. Schwaber, Ken. Agile Project Management with Scrum. Redmond Washington: Microsoft Press, 2004.

[2] http://scalingsoftwareagility.wordpress.com/category/release-planning/

[3] http://agileproductowner.com

Comments (0)

Write comment

Show/hide comment form