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, Agile 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 ApproachIn 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.

Skills and Attributes of the Enterprise Product Owner
However, none of this aggregated and beneficial user value can be delivered without the day to day cooperation of dozens of agile Product Owners, so the transitioning enterprise will need to find people to fill this role. In so doing, the enterprise should look for people with the following skills and attributes:

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.

Responsibilities
Given these attributes, what does the product owner actually do to drive successful outcomes? Generally, the activities of the Product Owner can be divided into three primary responsibilities:

• Driving the iteration
• Co-Planning the release
• Collaborating with Product Management

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

Owning the Iteration
As the iteration (see Figure 1) is the heartbeat of agility, we'll take some time to understand the Product Owners role in this critical process.

Iteration Planning

Each iteration starts with a structured planning meeting which is one of the key "ceremonies" in agile. The meeting is a 2-4 hr, time-boxed meeting with all team members in attendance. The objective of the meeting is to agree on content for the upcoming iteration

Preparation

Given the intensity and objective, the Product Owner should prepare in advance:

• 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 Planning Meeting

The meeting begins with reviewing the objective and then moves to discussion of the prioritized work in the backlog.

• 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.

The Result- A Committed Plan

The end result of an iteration planning meeting is an iteration plan that contains:

• 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.

Executing the Iteration

Thereafter, the primary responsibility for successfully executing ("landing") the iteration lies with the development team. The team members deliver the stories to the code baseline in priority order:

• 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.

Iteration Review - Accepting the Iteration

At the end of the iteration, a demo of the working, integrated software is held for all interested stakeholders. The format is as follows:

• 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.

Maintaining the Backlog

In addition to working the current iteration, however, the Product Owner must always be preparing for the next iteration-and the one after that-at the same time. Doing so involves maintaining the backlog- pruning and reprioritizing, adding new items that are discovered, prioritizing defects relative to new development, and accepting interdependent stories from other teams.

Just In Time Elaboration

In practice, countless iteration retrospectives have surfaced the common feedback:

"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.

Co-Planning the Release

Of course, the iterations serve a larger purpose - frequent, reliable and continuous release of value- added software to the customer or marketplace. Pictorially, this is seen in the Agile Enterprise Big Picture [1] as the Release (or PSI - Potentially Shippable Increment) boundaries in the figure below indicate.

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.

Collaboration with Product Managers

While the Release Planning event is one highly structured collaboration opportunity, the reality is that enterprise agility is most effective when Product Owners have a far more closely coupled relationship with product management. Indeed, I often recommend that Product Owners "report on a fat dotted.

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.

Building the Ultimate Agile Product Owner/Product Manager Team

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."

Conclusion

In this article, I've described the attributes and responsibilities of the critical role the agile Product Owner plays in helping the enterprise meet its objectives. And, with Jennifer's help, I've alluded to some tips to build an effective agile Product Owner and agile Product Manager team of teams.

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.

About the Author

Dean Leffingwell is an entrepreneur, executive, consultant and technical author who provides product strategy and enterprise-scale agility coaching to large software enterprises. Mr. Leffingwell has served as chief methodologist to Rally Software and formerly served as Vice President of Rational Software, now IBM’s Rational Division, where he was responsible for the RUP. He was also the founder and CEO of Requisite, Inc., makers of RequisitePro. His latest book is Scaling Software Agility: Best Practices for Large Enterprise and he is also the lead author of the text: Managing Software Requirements: First and Second Editions, both from Addison-Wesley. He can be reached through his blog at scalingsoftwareagilityblog.com

[1] the Big Picture of Enterprise Agility

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

[3] Systems of Systems and the Agile Release Train