Within many agile teams, the PO (product owner) is solely responsible for defining, interpreting and prioritizing requirements. Although these areas are clearly governed by the PO, making it the unique The PO province is fundamentally at odds with healthy agile team practices such as cross-functional teaming and collaborative spin-off.
Building a special box around the PO that others shouldn’t venture into is both unnecessary and unhealthy. These attempts appear to be the fulfillment of a wish for techies, as this segregation of duties could isolate the development team from most. people-centered software development tasks, which are notoriously difficult.
Instead of using the PO as a limit and buffer, agile teams benefit from sharing elements of the PO’s role with the designated PO, who should have the final say on the work to be done and whether or not it was successful. Here’s why.
The PO is the main steward of business value
In an agile team, the PO is primarily responsible for representing the needs of the business and ensuring that the team delivers business value. The PO develops the product backlog and prioritizes the elements of the backlog. During planning sessions, the PO ensures that the most important items are addressed first and helps define the acceptance criteria for these items.
Once the team has finished 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 delivering valuable results.
The order form is not a black box
In many teams, however, the role of the PO has been over-implemented. Since the PO is responsible for the requirements and prioritization, the team treats the PO as a living specification document. The requirements are what the PO says they are, and any questions about the requirements are resolved by asking the PO.
If there are any confusions that need to be resolved or priorities that need to be resolved, these activities are considered squarely within the scope of the OP, and the team waits for the OP to deal with the issues. The most messy and difficult aspect of software development – defining requirements – is left in the hands of one person. The team treats this individual as a layer of abstraction for various requirements management activities, such as education, research, strategic planning, and negotiation with stakeholders.
While the team likes to focus on cross-functional skills and spin-off on technical tasks, when it comes to requirements, which are the foundation of their work, they just squeeze the handle. toaster and wait for it to appear when ready. .
The isolated role of the PO is the fulfillment of wishes
The tendency of agile teams to share all roles except product ownership probably stems in part from the interests and inclinations of the development team. What I mean: The big fantasy of many software developers is to deal with code rather than people. While both present interesting challenges, the machines are much more maneuverable than their owners.
When developers cannot manage the technology on their own, they may prefer to deal with other technical people with whom they can easily relate. Otherwise, they would prefer to deal with a limited number of non-technical people who are well known to them. The role of PO, as some teams define it, is eerily like the fulfillment of wishes related to this fantasy. This allows technicians to hide messy, human-centric work that they often don’t do, such as behind a well-known person they are comfortable with. And it allows them to focus instead on the types of work they prefer to do.
In some contexts, this is reasonable. However, since the PO role is almost always a proxy for the needs of many other people, it is a fallible (albeit useful) layer of abstraction. The PO can be wrong, and sometimes the task of requirements engineering is too big for a single mind to handle.
Teams need to learn to step into the âPO Boxâ and help the PO deal with issues, recognizing that this leadership role has final authority over features and priorities.
Sharing the PO role
Development teams can help carry the burden of the OP in several ways, including:
Know the company
Development teams should understand the business considerations behind the software and know why certain features are valuable. This will help them ask better questions and make appropriate implementation decisions for low-level details that are not covered by the stated requirements.
Know the stakeholders
Development teams need to know who the app stakeholders are and how to get information from them. Routing every question of fact or intention through the PO will create an artificial and unnecessary bottleneck, especially in cases where the PO functions as a proxy for others. Teams must learn to stand behind the PO when further details or clarifications are needed. At the same time, they must keep the OP informed of these efforts, so that the OP retains the capacity to make informed and comprehensive judgments.
The PO is fallible, as are the stakeholders that the PO represents. Requirements will sometimes be poorly prioritized, missed and misinterpreted. The development team should use their business and technical knowledge to challenge seemingly misguided requirements, provide new requirements for consideration, and advocate for compromises motivated by implementation issues.
However, the development team must recognize that the PO has the final say on the team, otherwise the team will lack proper leadership.
Understand the economics of the project
The development team must understand the basics to prioritize certain jobs. They need to grasp the return on investment, payback periods, rates of return and the time value of money. They also need to understand the balance between time to market and technical debt. This knowledge will inform their engineering practices and lead them to break down epics and user stories in a way that delivers the highest value items first.
Think inside the “box”
By venturing inside the PO Box and sharing some of the traditional PO tasks, an agile team will become more knowledgeable, efficient, and fault-tolerant. The considerations that push them to share technical tasks also apply to the human side of their work.
Image credit: Flickr