Note: This is the fourth post in a series on the agile Product Owner and agile Product Manager‘s roles within the agile software enterprise. My primary collaborators on this series are Mauricio Zamora of CSG Systems, and Jennifer Fawcett of www.agileproductowner.com. In this post, I’ll describe some of the specific responsibilities of the enterprise Product Owner.
Earlier, 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, and defined the following matrix of responsibilities.
Agile Product Manager
Agile Product Owner
|Market/customer facing||Product/technology facing|
|Collocated & reports into marketing/business.||Collocated & reports into development/technology|
|Focuses on market segments, portfolio, ROI||Focuses on product and implementation technology|
|Owns the Vision||Owns the Implementation|
|Drives the Release||Drives the Iteration|
Responsibilities of the Agile Product Owner
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
Driving the Iteration
As the iteration (see Figure) is the heartbeat of agility, we’ll take some time to understand the Product Owners role in this critical process.
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 .
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 refactors, 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 as the Release (or PSI – Potentially Shippable Increment) boundaries in the figure below indicate.
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 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 line to product management” as the figure 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 prior posts, I’ve described the challenge of enterprise scale, noting that it is no trivial task to identify and train 10, 20 or even 100+ individuals to effectively implement the product owner role in the largest software enterprises. In the next post, I’ll provide some case study “vignettes”, which illustrate how some specific agile enterprises found the right people necessary to fill this role, along with some of the unique challenges they faced and the solutions they applied.