As organizations are moving toward Agile transformation, there is a revamp of several roles involved in software delivery. One role that is gaining popularity is that of a Product Owner. On the other hand, a traditional role that is losing its significance in this context is that of a Project Manager: a role that is not a part of the Scrum Team. While both Project Manager and Product Owner roles are accountable for the successful delivery of a product, there are differences between the roles and responsibilities of each. This article examines the project management skills that are essential for the success of Product Owners in a Scrum Team.
Scrum Team and Roles
The Scrum Guide describes the Scrum Team as a small team of people consisting of one Scrum Master, one Product Owner, and Developers.
The Scrum Master is accountable for establishing Scrum, as defined in the Scrum Guide.
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment for each Sprint.
The Scrum Guide mentions that the Product Owner is primarily accountable for effective Product Backlog management. Generally speaking, a Product Owner is expected to have sufficient technical skills to understand how product development happens, the architecture and COTS (commercial-off-the-shelf) products used, and the software delivery processes. However, depending on the Agile maturity of the organization and teams, a Product Owner is generally expected to be the “first among equals” assuming greater responsibility in ensuring product success. While technical skills are important, there are some other key skills that are essential for the success of Product Owners in such organizations to fulfill this expectation that some of the project management skills come in handy.
Essential Project Management Skills That Help Product Owners
The Project Management Institute (PMI) recognizes that the ideal skill set for a Project Manager is a combination of technical, leadership, and strategic and business management expertise.
Technical Project Management Skills
Technical project management skills are skills that a project manager uses to effectively apply project management knowledge to deliver the desired outcomes for programs or projects. PMBOK defines 10 areas of knowledge. This article focuses on a subset of 3 areas that would help a Product Owner to be successful: Risk Management, Stakeholder Management, and Cost Management.
Two other important areas, Scope Management and Schedule Management, are left out of this discussion as the checks and balances are in-built in the Scrum processes. A Sprint is a short, time-boxed period when a Scrum Team works together to deliver a shippable product version. Sprints are typically 2-4 weeks long.
Standard Scrum activities such as Product backlog refinement and prioritization, Sprint planning, the definition of ready, and the definition of done ensure that the scope of each item pulled into the Sprint is clear for the team and stakeholders. At the start of the Sprint, the Scrum Team pulls in just the amount of work that they are confident will be completed in the Sprint. Story points estimated on the prioritized backlog items and the velocity of the team are used to determine what gets pulled into the Sprint. Daily Scrum meetings and release burndown charts provide a clear view of whether the team is progressing well to achieve the Sprint objectives.
The International Standards Organization (ISO) defines risk as the “effect of uncertainty on objectives.” No matter what the objectives of a product team are, there is always a chance that things might go wrong.
Scrum daily meeting is an important tool for the Scrum Team to manage and mitigate any risks related to achieving Sprint goals. The team meets once a day, discusses briefly the progress each of the members had made the previous day, what they would focus on today, any impediments blocking them, and the means to resolve said impediments. Further, Scrum Teams mitigate the risk of the product not meeting the stakeholder expectations by building the product iteratively, making frequent releases.
While risk management is an integral part of the Scrum Team, there are other risks that the team should be cognizant of and should manage for the product’s success.
Generally, the following risk categories are relevant for any product:
- Business risk is the risk that customers don’t use the product as expected. This could be due to the product not meeting the customer needs or is not readily available when the customers need it.
- Technical risk is the risk that the cost of delivery of a product or feature exceeds the benefits derived from its release. It also encompasses the risk that the product cannot be easily maintained in the future.
Risk Management can be broadly considered as having the following phases:
Phase 1: Risk Identification
In this phase, the Product Owner along with the Scrum Team identifies all the risks that can potentially impact product delivery. Product Owners can engage with others outside the Scrum Team, such as key internal stakeholders and key customers to identify any other risks.
Phase 2: Risk Assessment
In this phase, the risk or likelihood of an occurrence and the impact if materialized are assessed. The net value impact of the risk is also evaluated in this step.
Phase 3: Risk Prioritization and Response
Identifying risk response is the next step. It is worthwhile to note that risk response could be one of the five categories: Escalate, Avoid, Transfer, Mitigate, Accept. What follows next is to create a risk-adjusted product backlog. This is done by transferring the risk actions that the Scrum Team has an influence on into the product backlog, reviewing them along with the existing product backlog items, and re-prioritizing the entire backlog. The net value impact of the risks is an important factor that helps in establishing the priority with which the risk actions are to be addressed.
Phase 4: Risk Monitoring
This is a continuous process through which risks are monitored and the previous phases of identification, assessment, response, and prioritization are repeated so that the Scrum Team is addressing risks appropriately and ensuring product success.
As mentioned earlier, Scrum defines 3 main roles: Product Owner, Scrum Master, and Scrum Team. In addition to these roles, there are other parties, a.k.a stakeholders, who play an important role in the success of a product. A stakeholder is anyone who is interested in the product or involved with or impacted by the product. Stakeholders could be internal or external to the organization.
Typical stakeholders are:
- Decision-makers such as Product sponsors, Board of directors, Senior Executives, etc.
- Users of the product
- Internal departments like Legal, Security, Marketing, Audit, and Compliance, etc. that have specific contributions towards the successful launch and operation of the product
It is the primary responsibility of a Product Owner to ensure that the product vision and features are aligned with the expectations of stakeholders. Hence, it is crucial that the stakeholders are engaged throughout the product life cycle.
Stakeholder management constitutes of three phases:
Phase 1: Identify Stakeholders
In this phase, the Product Owner identifies all the stakeholders that need to be engaged during the product life cycle. As mentioned above, stakeholders could be both internal and external.
Phase 2: Analyze Stakeholders
In this phase, the Product Owner should analyze the stakeholders to understand their expectations, their level of engagement, and the impact they could wield on the product direction. Further, the Product Owner should prioritize stakeholders and arrive at an appropriate communication plan. One golden rule to remember is: “All stakeholders are not equal.” This analysis phase helps a Product Owner to determine the most appropriate way to engage them. For instance, a 1-1 communication works best in some situations for some of the stakeholders whereas a periodic product update could be enough for some of the stakeholders
Phase 3: Engage Stakeholders
This is the phase where execution happens and the Product Owner should ensure that the appropriate stakeholders are informed or engaged in the most appropriate fashion.
Organizations of every size and nature care about cost management, as it enables monitoring the business’s financial health and provides information for decision-making that leads the company to sustainable growth.
At the product level, it is necessary to have cost management aspects in place to have a good view on the profitability of a product or product feature based on which product sponsor could take decisions about the investments that should be made into the product development.
The PMBOK defines a set of processes under the Cost management knowledge area to identify and manage costs on a project covered. The premise here is that the scope is fixed and hence an elaborate cost estimate and plan can be laid out.
However, in highly unpredictable Agile environments where the scope is not defined upfront, a more lightweight cost management process can be followed to establish the budget needed and control the costs.
This phase focuses on getting a view of the budget required for the product or feature delivery. Budget involves both the labor costs and the CAPEX/OPEX costs needed for software licenses, infrastructure, etc.
Scrum teams use any one of several approaches, like Planning Poker and Affinity Grouping, to estimate how big or small a particular user story is. Based on this estimate, the team decides what backlog items they can pull into the Sprint.
While these techniques are good enough for Sprint planning, there are often times when organizations need to address questions like, “Do we have the funds to deliver this product or product feature?” or, “What is the rough order of magnitude of budget needed to deliver XYZ product or feature?”
Precision Alignment Approach
To begin with, a prioritized list of product features is established. The Scrum Team, based on its previous experience, provides a rough range of cost estimates for each of the features. Adding up all the costs provides the range of cost estimates needed to deliver the product features. With this information, the product sponsors can decide whether there are enough funds available to develop the features listed in the backlog.
Once the budget needs are established and approved, depending on the organization’s processes, funding for the product development will be made available. In some organizations, a budget could be approved for a set of features or a budget could be approved at the beginning of each iteration.
This is a continuous process through which budget consumption is monitored. A release burndown chart is a good way to measure whether all the features foreseen in the release will be delivered at the end of the Sprint. This confirms whether the cost estimated for a feature is staying within the range or not. If the feature’s actual delivery costs go way off from the estimates, the Product Owner should first discuss with the team ways to address this deviation, and then inform the product sponsor, who can then decide whether it makes sense to continue developing this feature or not.
Strategic and Business Management Skills
Strategic management is the continuous process of planning, monitoring, analyzing, and assessing everything that is needed for an organization to meet its goals and objectives. It involves deciding what is important for the long-term success of the business and focusing on it.
A diversified company has its strategy established at three levels.
At this level, the overall direction of the organization is established. It establishes what businesses the corporation should be involved in and how the corporate office should manage the different business units.
At this level, the strategy is concerned with how to create a competitive advantage in each of the businesses in which a company is involved.
It is the approach a business function takes to achieve corporate and business unit objectives and strategies by maximizing resource productivity. It deals with a relatively restricted plan that provides the objectives for a specific business function.
Though the strategy is established at three different levels, they depend on each other, and one level cannot succeed without the success of the other levels.
The most common way that many organizations approach setting organizational strategy is a top-down approach wherein goals and their corresponding business and functional goals are defined at the top level and moved from the top to the bottom level of a hierarchy. The biggest drawback of this approach is that it misses out on taking advantage of the knowledge that staff will be able to add to the strategic management process.
Another approach for setting the organizational strategy is following the bottom-up approach where goals set at the lower levels of the organization are rolled up to the upper levels. While this approach helps in taking advantage of the knowledge staff possesses, it brings in its own disadvantages like lack of cohesion or ego clashes when the different departments do not align on the objectives and goals.
Hence, a hybrid approach that combines both the top-down and bottom-up approaches to establish organization strategy is best suited for Agile organizations. It is in this context that a Product Owner can act as a glue to ensure that the top-down and bottom-up approaches come together cohesively.
A Product Owner who has an understanding of the broader, longer-term vision of the organization and in-depth domain knowledge, which is understanding of the product and market conditions, can help further the strategic objectives of the organization and succeed in his or her role. By aligning the Product roadmap and product backlog to the organizational strategy, the Product Owner should ensure that the Scrum Team focuses on the right priorities. By providing senior management inputs on the market conditions, customer feedback, etc., the Product Owner should ensure that the organization is laying out a good strategy.
In a Scrum Team, there is no hierarchy. All members are peers to each other.
The Scrum Guide mentions the following about the definition of a Scrum Team: “The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”
A large part of a Product Owner’s role involves dealing with people. A Product Owner should develop situational leadership skills to be able to assess the conditions of the work environment, organizational objectives, strengths, and weaknesses of the team members and adopt a leadership style that best fits the situation.
Situational leadership styles that a Product Owner should develop include:
- Tell: This is the style a Product Owner should adopt when the team is not yet self-organizing or has just started on its Agile journey. A Product Owner should set up the basic processes needed to help the team gain confidence and move in the Agile direction.
- Sell: A Product Owner should adopt this style when the team is gaining confidence in its own abilities and Agile maturity. The team starts to be involved in decisions, and the Product Owner provides the necessary support and encouragement.
- Participate: A successful Product Owner adopts this style of leadership when the Scrum Team gains confidence in their skills and Agile maturity. The Product Owner is available to encourage and support the team, but it is clear it is the team that is most responsible for making decisions. Such a team is well on its way to becoming truly self-organizing.
- Delegate: A Product Owner should adopt this style when the team is on higher levels of Agile maturity. The product Owner offers minimal guidance, available to help but does not specify how work is to be accomplished.
To conclude, some skills that were traditionally considered to be Project Management skills are essential for the success of a Product Owner. Does that mean that any Project Manager can become a successful Product Owner? Not necessarily. Does that mean a Product Owner should have Project Management experience to be successful? Not necessarily. However, picking up some of the Project Management skills and putting them to use depending on the situation would definitely help Product Owners to succeed.