Size matters in agile. The agile team size is typically linked to scope and delivery capacity based on user stories. As discussed in a previous post, the Product Owner indirectly owns the scope / requirements, business facing plans, acceptance and success criteria—but this is not for him or her to manage delivery, which is the role of the Agile Project Manager.
The Product Owner is product oriented rather than project oriented, accountable for value realization and budget management; he or she maintains the backlog and adjusts the business case on an ongoing basis, using it as a framework to make decisions. This allows for ongoing experimentation, value-based adjustments and flexibility as detailed requirements are decomposed within the given scope and timeframe boundaries.
In this post, I expand on the 9 core activities of the Product Owner as introduced in the previous post; and discuss how these relate to other different stakeholders when implementing PLM solutions.
Agile development is not new (see its Wikipedia page), it emerged in the 1970s as the foundation for software development; an approach to discovering requirements through collaborative efforts, and promoting:
- Individuals and interactions over processes and tools
- Working “products” (i.e. solutions) over comprehensive documentation
- Customer collaboration over contact negotiation
- Responding to change over following a plan
Scrum is an (the most popular?) agile development framework which help teams deliver on the above items highlighted in bold, by organizing frequent deliveries and opportunities for adjustment—as such:
A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
—the Scrum Guide (2017)
Going back to the Product Owner role, core activities relate to value, business engagement, backlog, sprint and release planning. Considering PLM journeys, it is often acknowledged that ‘the devil is in the details’ and that detailed requirements are discovered during experimentation. Therefore, the following 9 activities cover a day in the life of the Product Owner applied to PLM implementations (considering “PLM as a solution”, not just the tool / system).
Managing business stakeholders
The business is the customer, and the customer is king. Though this might be easy to translate for simple requirements, it is often necessary to educate the business about the ‘art of the possible’: what are the possible approaches to solve a problem, what are the pros and cons of each options, which one is recommended and why.
The Product Owner is expected to build relationships with the business and act as a ‘trusted advisor’ in being open and transparent.
Managing business value
Value discovery drives everything in agile delivery. The need to have clear success factors (CSFs) and performance metrics (KPIs) is therefore essential, though especially contained to the current and perhaps next iterations, rather than the prospective scope as a whole.
How this is done may vary across projects, organizations, agile / scrum teams and individuals. The Product Owner is the ‘value realization’ gatekeeper and interface to the business.
Defining the MVP and acceptance criteria
Business acceptance is critical, like for any projects in size and scope. The minimum viable product is not an end as such, but a mean to reach a stable foundation for further development.
The Product Owner is to agree with the business MVP expectations in value terms and how the solution will be accepted through each sprint.
Managing and prioritizing the backlog
The “product” backlog is actually an evolving requirement list, some of which are more qualified than other; everyone can input into the backlog, and it is used as a delivery “triage tool”. Having a growing number of requirements is fine and measuring how they may span across releases and their associated value to the business is critical to prioritize their delivery.
As the sole person responsible for managing the backlog, the Product Owner has the final say on prioritizing the backlog requirements, both based on value and technical dependencies with the MVP.
Managing the current sprint and release
Based on the backlog related decisions, delivery is prioritized with the implementation team(s) as detailed scope is gradually confirmed. As referred in the Scrum Guide, scope clarification is done on an ongoing basis:
No changes are made that would endanger the Sprint Goal; quality goals do not decrease; and, scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. Each Sprint may be considered a project with no more than a one-month horizon.
—the Scrum Guide
The Product Owner drives the content for the current sprint and release plans.
Maintaining the next sprint and release plan
Similarly, per the current sprint and release plans, the Product Owner drives content prioritization for the next sprint and release plans—progressively going into details. The backlog is adjusted to meet new opportunities and as requirements get cascaded or added.
Aligning the business roadmap
The overall roadmap is continuously updated to reflect new findings; the Product Owner plays a key role is communicating and justifying decisions related to adapting the roadmap.
Prioritizing deliverables and understanding dependencies
Prioritizing content (what) does not mean managing the delivery team (how the solution will be delivered); the latter is the role of the Project Manager and Team Leads.
The Product Owner must work closely with delivery teams to understand dependencies and how to translate any implications into (value-based) business terms. PLM dependencies can be very complex due to operating constraints, processes and relational data inter-dependencies.
Providing feedback to the delivery teams
Collaboration implies providing and getting feedback. As the main interface to the business, the Product Owner must be a good listener and able to balance different perspectives.
By default, agile teams must remain small (8-10 people max). Based on product complexity, it is sometimes required to appoint more than one Product Owner to interface with each agile team, possibly under the direction of a Product Manager to focus on the overall “product” attributes.
What are your thoughts?
References:
- Jim Highsmith, for the Agile Alliance (2001) History: The Agile Manifesto [last accessed: 22 October 2020]
- The Scrum Guide (2017) [last accessed: 22 October 2020]
This post was originally published on Momentum-PLM on 2 November 2020.
Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption.
About the Author
