Within many agile teams, the PO (product owner) is solely responsible for the definition, interpretation, and prioritization of requirements. While these areas are clearly ruled by the PO, making them the unique province of the PO is fundamentally at odds with healthy agile team practices such as cross-functional teaming and collaborative swarming.
Building a special box around the PO into which others should not venture is both unnecessary and unhealthy. Those attempts seem like wish fulfillment for technophiles, since this separation of duties might insulate the development team from many of the people-centered duties of software development, which are notoriously challenging.
Instead of using the PO as a boundary and buffer, agile teams benefit from sharing elements of the PO role with the designated PO, who should retain final say over what work needs to be done and whether or not it has been successful. Here's why.
The PO is the chief steward of business value
On an agile team, the PO is principally responsible for representing business needs and ensuring that the team delivers business value. The PO develops the product backlog and prioritizes backlog items. In planning sessions, the PO ensures that the most important items are worked first, and helps to define acceptance criteria for those items.
Once the team is done working on the items, the PO verifies that the acceptance criteria have been met. Overall, the PO ensures that the team is working on the right features and producing valuable outcomes.
The PO is not a black box
On many teams, however, the PO role as implemented in an exaggerated fashion. Since the PO is responsible for requirements and prioritization, the team treats the PO as a living specification document. The requirements are whatever the PO says that they are, and any questions about the requirements are resolved by asking the PO.
If there are confusions that need to be sorted out or priorities that need to be de-conflicted, those activities are thought to be squarely in the the PO's domain, and the team waits while the PO goes to figure things out. The messiest and most difficult aspect of software development—nailing down the requirements—is left in the hands of a single individual. The team treats that individual as an abstraction layer for a variety of requirements management activities, such as education, research, strategic planning, and stakeholder negotiation.
Even though the team likes to emphasize cross-functional skill sets and swarming on technical tasks, when it comes to requirements—which are the foundation of their work—they are content to push down the toaster handle and wait for it to pop up when ready.
The isolated PO role is wish fulfillment
The tendency for agile teams to share all roles except product ownership likely derives in part from the interests and proclivities of the development team. By which I mean: The great fantasy of many software developers is to deal with code instead of people. While both present interesting challenges, machines are much more tractable than their owners.
When developers can't deal with technology alone, they might like to deal with other technical people to whom they can easily relate. Failing that, they would prefer to deal with a limited number of non-technical people who are well known to them. The PO role, as some teams define it, sounds suspiciously like wish fulfillment related to this fantasy. It gives technical people license to hide the messy, human-centric work they often don't, like behind a particular well-known person with whom they are comfortable. And it allows them to instead focus on the kinds of work they prefer to do.
In some contexts, this is reasonable. However, since the PO role is almost always a proxy for many other people's requirements, it is a fallible (albeit useful) layer of abstraction. The PO can be wrong, and sometimes the task of requirements engineering is too large for a single mind to handle.
Teams need to learn to get inside "the PO box" and help the PO sort things out, while recognizing that this leader role has final authority over features and priorities.
Sharing the PO role
Development teams can help carry the burden of the PO in several ways, including:
Knowing the business
Development teams should understand the business considerations driving the software, and know why certain features are valuable. This will help them to ask better questions and make appropriate implementation decisions for low-level details that aren't covered by the stated requirements.
Knowing the stakeholders
Development teams should know who the application stakeholders are and how to get information from them. Routing every question of fact or intent through the PO will create an artificial and pointless bottleneck, particularly in cases where the PO functions as a proxy for others. Teams must learn how to get behind the PO when additional details or clarifications are needed. At the same time, they must keep the PO in the loop on any such efforts, so that the PO retains the ability to make informed and comprehensive judgments.
Challenging requirements
The PO is fallible, as are the stakeholders the PO represents. Requirements will sometimes be wrongly prioritized, missed, and misconstrued. The development team must use their business and technical knowledge to challenge requirements that seem misguided, supply new requirements for consideration, and argue for compromises motivated by implementation concerns.
However, the development team must recognize that the PO has final say in team matters, or else the team will be missing adequate direction.
Understanding project economics
The development team should understand the basis for prioritizing certain work. They must grasp ROI, payback periods, rates of return, and the time value of money. They should also understand the balance between time to market and technical debt. This knowledge will inform their engineering practices and drive them to decompose epics and user stories in ways that deliver the highest value elements first.
Think inside the "box"
By venturing inside of the PO box and sharing some of the traditional PO duties, an agile team will become more informed, efficient, and fault-tolerant. The considerations that drive them to share technical tasks are equally applicable to the human-centric side of their work.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
