The primary goal of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team, being the first source of information about the problem domain for the team. Each agile team, or in the case of large programmes an agile subteam, has a single product owner to go to for information and prioritization of their work and they do so right away. A secondary goal for a product owner is to represent the work of the agile team to the stakeholder community. In traditional terms, a product owner is in many ways an empowered business analyst without the burden of the bureaucracy surrounding big requirements up front (BRUF).
The role of product owner was introduced to the agile community by Scrum, although the onsite customer practice of Extreme Programming (XP) is very similar. This role has been adopted by the Disciplined Agile (DA) tool kit.
As a stakeholder proxy, the product owner:
- Is the “go to” person for domain information
- Provides timely information and decisions
- Prioritizes requirements, defects, and other work items for the team
- Is an active participant in modeling (sometimes mistakenly called backlog grooming or backlog refinement)
- Is an active participant in customer testing
- Helps the team gain access to expert stakeholders
- Facilitates requirements modeling sessions, including requirements envisioning
- Educates team in the business domain
- Is the gateway to funding
- Manages requirements dependencies with other teams, negotiating and reprioritizing as appropriate
When representing the agile team to the stakeholder community, the product owner:
- Is the public face of the team to stakeholders
- Demos the solution to key stakeholders who weren’t able to attend the regular demo
- Announces releases
- Communicates team status
- Organizes milestone reviews
- Facilitates requirements modeling sessions
- Educates stakeholders in the development process
- Negotiates priorities, scope, funding, and schedule
There are several aspects about this role which I think are critical to understand:
- Product owners bridge the communication between the team and their stakeholders. As Figure 1 shows, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a team representative to the overall stakeholder community as a whole.
- Product owners are empowered. The product owner is the single person whom is responsible for prioritizing requirements and for providing the details explaining the requirements to the team. At scale this becomes a bit more complex, as you’ll see below.
- Product owners facilitate communication. Product owners need good communication skills, including agile modeling skills. They also need to know who the stakeholders are, interact with them regularly, and when needed facilitate the interaction which the team has with them. Although it’s convenient for delivery teams to think of product owners as the “one neck to wring” because it puts the burden of requirements responsibility on them, the reality is that the product owner can’t possibly know all the details known by the true range of stakeholders at all points in time and as a result will need to bring stakeholder experts to the team to share their expertise with the team at appropriate times. The implication is that the product owner isn’t always the direct source of requirements.
- Product owners prefer direct means of communication. There is significant evidence that the worst way to communicate information between people is via documentation, and that the most effective way is face-to-face around a shared sketching environment. Agilists in general prefer to avoid interim documentation and instead use more effective means for agile communication.
- Product owners need many business analysis skills. They need to be skilled in techniques to identify stakeholder needs, negotiate priorities between repeating stakeholder factions, and then collaborate with developers to ensure that the requirements are implemented effectively. This is business analysis 101 stuff.
Figure 1. The role of Product Owner (click to enlarge).
Product Owners at Scale
Figure 2 depicts a typical organization structure for a large agile team. The subteams will be organized either around the architecture of the system (a component team approach), around the requirements (a feature team approach), an internal open source strategy, or combinations there of. Regardless, each of the subteams will need to have access to a product owner (although any given product owner could work with more than one subteam). The product owners will be part of the product owner team, lead by a chief product owner. This product owner team will:
- Manage the requirements for the overall program
- Negotiate functional dependencies between requirements being implemented by different subteam, potentially reprioritizing requirements to reflect those dependencies
- Manage consistency of the requirements between subteams
- Assign requirements between subteams in a consistent and sensible manner
To do these things the product owner team will need to coordinate regularly. There are several strategies to do so:
- Have their own daily coordination meeting
- Have a regular, perhaps weekly, meeting to discuss any requirements issues between subteams
- Adopt electronic requirements management tools
- Combinations of the above
Where Do Product Owners Come From?
The goods news is that there are several viable options for where Product Owners may come from:
- Business analyst. Although a traditional business analyst could fill the role of product owner, there is a risk that they will fall into their old habits of communicating via documentation. Keep in mind that what agile teams really need are people with agile analysis skills who are empowered to make decisions. So, a better option is an empowered agile business analyst.
- Business stakeholder. When business stakeholders are trained to be POs they are often very knowledgeable about the part(s) of the business where they have worked. However, they are often week on their new PO skills (understandably slow), potentially weak on parts of the business where they haven’t worked, and often weak on the non-business aspects of your organization (including operations, support, audit, the existing infrastructure, and so on).
- IT stakeholder. IT stakeholders have similar challenges to business stakeholders when in the role of PO. They are often strong in IT although weak in other aspects of your organization.
- Product manager. Organizations producing software solutions for the marketplace, will often have established product management groups. The key challenges always seems to be freeing up the product manager to spend sufficient time with the development teams when in the role of PO, and for them to provide the details required by the teams.
- New hire. This is hard to make work in practice. Although you MAY be able to hire someone with solid PO skills, they won’t have the contacts that they require to do the job well. It can take many years to do this. However, if your organization is small this is a viable option.
My experience is that the best product owners are empowered stakeholders (from either the IT or business side) who have been educated, trained, and mentored in the role of product ownership. Having said that, it is often very difficult to find such people who are willing to fill the role of PO.
The role of PO is very hard to fill. Even when provided good training, which doesn’t happen as often as it should, it will still be a struggle.
|This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.|
|The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams. Furthermore, this book describes the fundamental programming and testing techniques for successful agile solution delivery. The book also shows how to move from your agile models to source code, how to succeed at implementation techniques such as refactoring and test-driven development(TDD). The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.|