Product Owner’s Journey to SAFe^®—Role Changes in Scaled Agile Framework^®

Abstract

As agile software development methods are spreading through the industry, they are no longer sufficient in their original design. With the increasing adoption by various types and sizes of organizations, these methods are scaled and tailored. The most popular framework for scaling Agile is the Scaled Agile Framework^®, registered trademark of Scaled Agile, Inc. Boulder, USA. Some roles originating from the agile methods, such as Product Owner, are part of the framework and are impacted by scaling and tailoring. A Product Owner role is critical to the success of projects in agile environments. This paper aims to describe and discuss the evolution of and changes in Product Owner activities since Agile started to spread in the industry until the current concept of the Product Owner role in the Scaled Agile Framework. By identifying the activities typical of Product Owners outside of the Scaled Agile Framework context and mapping these activities to the Product Owner role description in Scaled Agile Framework, the changes in Product Owner role with respect to time and role specifics in the Scaled Agile Framework are revealed. It was identified that some of the activities previously described for Product Owner are distributed between various roles in the Scaled Agile Framework. In fact, the Product Owner loses the real product ownership in Scaled Agile Framework. The loss of ownership seems connected with the fact that, in the large environments that the Scaled Agile Framework is designed for, it is impossible to cover all required activities by one role using the hierarchical structures with a top-down approach in the Scaled Agile Framework.

1. Introduction

Agile as an approach to software development has become common practice. According to previous research, 73% of organizations use agile practices at least sometimes [1]. Agile is incremental and iterative software development done by closely collaborating teams [2]. The most common agile method used is Scrum [3]. The Scrum process was discussed by Sutherland and Schwaber [4] at the 1995 Object-Oriented Programming, Systems, Language and Applications (OOPSLA) conference for the first time. Three roles were defined within the process: Product Owner (PO), Development Team, and Scrum Master. Scrum became very popular [3], albeit sometimes in a different form than its originators had in mind [5].

Despite the original orientation toward small teams, agile methods also became popular in large companies [6,7]. The original design of agile methods is no longer sufficient [8]. Thus, tailoring and scaling agile methods to organizations’ particular requirements is an absolute necessity [9,10]. Instead of rigidly following the single method prescriptions, selecting, adapting, and combining practices represent the reality [11]. As an answer to the need for applying Agile at scale, various frameworks for scaling Agile emerged [12]. According to the 14th State of Agile Survey [3], the Scaled Agile Framework^® (SAFe) is the most popular framework across large enterprises, as 35% of respondents marked SAFe as the framework they use for scaling Agile. SAFe [13] provides prescriptive guidelines for implementing an enterprise-scale Lean-Agile development. The roles originating from the Scrum are perceived in SAFe, but additional roles influencing the product development are defined, i.e., Product Manager or System Architect [13], who closely collaborate with the Product Owner in SAFe [14].

Although the Product Owner has been identified to play a crucial role in the success of projects in large-scale environments [9], any mention of SAFe in research papers on Product Owner in large-scale environments [15,16,17,18,19] is scarce. Additionally, staffing the right Product Owner was identified as one of the major challenges when adopting SAFe [20]. The causes of this challenge were not described.

Research problem. Considering the increase in the adoption, scaling, and tailoring of Agile, it is evident that the original concept of the methods and roles had to evolve, including the Product Owner role. Therefore, the challenge with staffing the right Product Owner [20] can originate from an insufficient understanding of Product Owner role specifics in the context of SAFe. Hence, this is a research gap to be filled. By revealing the specifics of the Product Owner role in SAFe, this paper aims to (1) support enterprises in acknowledging the requirements to people assigned to the Product Owner role and, therefore, help with their SAFe adoption, (2) help Product Owner candidates in understanding the Product Owner role’s specifics in SAFe compared to the PO role’s generic concept, and (3) contribute to filling the gap in research on Product Owner in SAFe.

The evolution and changes in the Product Owner role activities since Agile started to spread in the industry until the current product owner role in SAFe were the focus. First, we viewed the contemporary generic concept of the role through the lens of time and then mapped it to the Product Owner role specifics in SAFe.

2. Materials and Methods

The research problem was derived from an initial literature review on the state of research on Product Owner and SAFe. The results of the literature review are presented in Section 3.1. As we decided to reveal the specifics of the Product Owner role in SAFe, our research addresses the following research question (RQ): Which Product Owner activities described so far are prescribed for Product Owners in SAFe? An activity is understood as the work of a person, group, or organization to achieve something [21]. We defined the following objectives (OBJn) to answer the RQ: (OBJ1) Conduct a literature review on Product Owner activities; (OBJ2) Extract and categorize the activities performed by the Product Owner; (OBJ3) Create a timeline representing the evolution of activities performed by Product Owner; (OBJ4) Compare the identified Product Owner (PO) activities with the description of the PO in SAFe.

OBJ1—Conduct a literature review on Product Owner activities. To find appropriate publications, we followed the mapping process described by Kitchenham et al. [22]. (1) Define: Our focus was to identify publications containing the description of Product Owner activities. (2) Organize: First, we targeted AMC Digital Library as the world’s largest scientific and educational computing society and the eResources of the Czech National Library of Technology, which cover multiple databases (i.e., SpringerLink, Wiley Online Library, Science Direct, IEEE/IET Electronic library). Next, we searched Google Scholar to include metadata provided by other major publishers. (3) Execute: The search was conducted using the following keywords: Scrum, Agile, Product Owner, Product Owners, PO, and POs. After the initial screening, when the papers were evaluated by title and abstract and publications with no relation to the Product Owner role were excluded, 28 papers were passed for further review.

To review the papers, the approach described by Keshav [23] was used. First, the remaining publications had the introduction and conclusions reviewed, and those with no valuable information were excluded. The remaining papers were studied and analyzed in detail. The publications with assumed relation to the Product Owner, which were cited in papers during the analysis, were extracted and reviewed using similar initial review steps. The whole process resulted in 23 papers touching on Product Owner activities. To enrich the information source and better connect it to the practice, we decided to include practitioners’ books [24,25,26,27,28,29,30]. Due to the lack of papers describing the early adoptions of Scrum, other documents and presentations available for this era were added [31,32,33].

OBJ2—Extract and categorize the activities performed by the Product Owner. For the extraction and categorization of the activities, a content analysis process [34] was used with the following steps: (1) Manually select and make sense of the data; (2) Develop analysis matrix; (3) Gather data; (4) Group headings to make classifications; (5) Cerate abstractions/descriptions; (6) Report model, concepts, or categories.

The identified publications were read in detail with the extraction of the activities discovered in the text. Those with similar meanings were merged and then divided into categories. Five categories were defined on the basis of areas of the Product Owner’s responsibilities: Backlog, Project, Team, Customers and Business, and Development. The activities falling under each category were then chronologically ordered by date of publication. Although similar activities were mentioned several times in studies, only the first mentioning of the activity was considered for the listing. Additionally, we validated the identified activities through mapping to the activities identified by Unger-Windeler et al. [35]. The activities newly identified during the conduction of this study were listed separately.

OBJ3—Create a timeline representing the evolution of activities performed by Product Owner. To create the timeline, we used a simple method of chronological ordering. The identified activities were positioned on a timeline and their change throughout time was discussed. Even here, only the first mentioning of an activity was considered to avoid redundancy in the list and to improve the readability of the timeline.

OBJ4—Compare identified Product Owner activities with the description of the Product Owner in SAFe. A deductive content analysis [34] was used. First, the Product Owner role in the context of SAFe was analyzed using the materials available on the official SAFe website [13]. Then, the activities previously identified and categorized (OBJ2) were mapped to the description of the Product Owner role available in SAFe to confirm or disprove their prescriptions for the Product Owner in SAFe. This part of the process was conducted manually without any automation or special software tools. Lastly, the results were summarized, and they are presented in Section 3.

3. Results

We divide this section in two main parts. First, in Section 3.1, we present the results of the current state of research in the selected area. Then, in Section 3.2, the outcomes of the conducted research are described.

3.1. Background

This subsection provides a literature review on the Product Owner role, reflecting the state of research in the examined area. Next, it gives a brief introduction to SAFe and drafts the Product Owner role specifics within SAFe.

3.1.1. Product Owner Role

The Product Owner role originates from Scrum [3]. Sutherland and Schwaber [4] discussed the new process for software development called Scrum at the 1995 OOPSLA conference for the first time. Three roles were defined within the process: Product Owner (PO), Development Team, and Scrum Master. In Scrum, the work is done in iterations of 1–4 weeks called Sprints, each aiming to deliver a potentially releasable product increment [36]. Every increment contains implemented requirements selected by the Product Owner, who is accountable for maximizing the value of the product resulting from the Development Team’s work and for effective Product backlog management [36]. The Product Owner closely collaborates with (1) the Development Team, which is self-organized and works independently during the Sprints, ending each Sprint with a demonstration of a potentially releasable increment, and (2) the Scrum Master, whose role is to eliminate any emerging impediment and enforce the Scrum Process [37].

The Product Owner role has been given some attention in previous research. Sverrisdottir et al. [38] compared the theoretical description of the role with practice and concluded that real-life implementation differs from Scrum’s theory. They described Product Owner as a very difficult role since the Product Owner’s success depends on many factors such as organizational culture, project type, management approach, and the interaction within the team that is developing the product. A case study at Spotify was done by Kristinsdottir et al. [39], focusing on the Product Owners’ responsibilities and challenges. There was no explicit agreement among the interviewees on the actual daily responsibilities, as there were many tasks to juggle each day. “Some respondents commented that they needed to have one foot in the daily work and one foot in the future and lead people to work on the right things at any given moment” [39] (p. 13). The study confirmed that Product Owner is a complex role with both inward- and outward-facing responsibilities. Unger-Windeler et al. [35] did a mapping study on Product Owners in industry. They highlighted the impact of external circumstances on the Product Owner role as an area for future research. Furthermore, Unger-Windeler et al. [35] concluded that the Product Owner role in large-scale projects is clearly defined as a group effort, and the Product Owner’s management and leadership responsibilities remain unanswered.

3.1.2. Product Owner Role in Scaled Environments

Researchers also focused on the Product Owner role in large-scale environments. Paasivaara et al. [19] described the differences in approaches to the Product Owner role’s scaling. Bass [16] found that more people forming the Product Owner teams are required to manage the scale and complexity of Product Owner activities in globalized software development projects. Bass then identified nine functions that Product Owner teams perform in large-scale Agile [15] and later enhanced the previously introduced taxonomy with an additional three sets of activities [17]. Furthermore, according to Bass and Haxby [17], with adoption on a large scale, Product Owners must cope with a range of new responsibilities, a wider range of stakeholders with conflicting needs, and expanding workloads. Bertzen et al. [18] identified the importance of frequent communication and interaction between Product Owners in large-scale Agile. Despite SAFe being the most popular framework for scaling Agile [3], none of the mentioned studies focused on or considered SAFe.

3.1.3. SAFe

SAFe provides prescriptive guidelines to implement enterprise-scale Lean-Agile development [13] in large enterprises, and many companies that have applied SAFe reported significant benefits from it [13]. Several agile practices were incorporated and blended in SAFe [20]. Together with specific SAFe processes, these methods form a complex framework with many defined roles. Different configurations of SAFe are available to better fit specific enterprise environments and address the need for scalability: Essential SAFe, Large Solution SAFe, Portfolio SAFe, and Full SAFe [13]. According to the selected configuration, different levels of the framework are added. Each level carries out its activities, and all levels are tied together [40]. In SAFe, four levels (layers) of organization are present: Team, Program, Value Stream, and Portfolio. At least Team and Program levels are present in each of the possible SAFe configurations. Even in the Essential configuration, SAFe is complex and provides a huge set of templates, process elements, and roles [41]. Some practitioners consider SAFe too heavy and complex, and some even say that SAFe adds complexity to bureaucracy, evolving into “the new waterfall” [41]. Other concerns are related to agile principles and values in the top-down approach and SAFe’s strong emphasis on process rather than on people [42,43,44]. Despite many existing success case studies available on the SAFe official webpage [13], there was little research about SAFe implementations done [20]. Calls for further research were made [9,14,20], as well as for investigation into how the challenges are overcome in enterprises emphasized [20]. Putta et al. [20] stated that staffing the right Product Owner is one of the major challenges.

3.1.4. Product Owner Role in SAFe

The Product Owner is positioned on the team level. SAFe implies that a single person cannot handle product and market strategy while also being dedicated to agile teams. It was confirmed in [17] that, on a large scale, the scope of activities goes beyond the capacities of one person acting as Product Owner. The Product Owner and the Product Manager share responsibilities for working with customers [13], while the Product Manager is the prime customer-facing role. The Product Owner is responsible for the agile team’s backlog, which is essential to correctly allocating the teams’ capacity across conflicting needs. The Product Owner is the only owner of the Team backlog and uses their ownership to protect the team from divergent views on importance from different stakeholders. Team backlog consists of stories and enablers. However, there is no concept of Product backlog, typical for Scrum, used in SAFe. The closest analogy is arguably Program backlog. Program backlog consists of the features and enablers defined by the Product Manager. The Team backlog can then be understood as a subset of the Program backlog. The Product Owner collaborates closely with the agile team, which defines, builds, tests, and delivers increments of value, the System Architect, who creates an architectural vision and aligns teams around a shared technical direction, the Scrum Master, who ensures agile process is being followed, and the Release Train Engineer, who facilitates agile release train events and processes and assists the teams in delivering the value [13]. SAFe defines various other roles, not in regular direct contact with the Product Owner. Hence, we do not describe them in this paper.

Limited research on the Product Owner role has been done. The study of Paasivaara et al. [14] stated that implementing SAFe results in closer collaboration and communication between Product Owners and Product Managers. However, the study’s focus was on SAFe adoption in general. Remta et al. [42] presented the preliminary outcomes of the empirical research on the Product Owner role in a selected organization that follows SAFe, indicating that the Product Owner’s accountability for product leadership in SAFe is ceasing. We did not identify other papers dealing specifically with the Product Owner role within the context of SAFe during the literature review. Overall, little is known about the Product Owner in SAFe and the role specifics.

3.2. Research Outcomes

In this subsection, we describe the origin of the Product Owner role and create a generic concept of the role activities on the basis of the reviewed publications. Next, the identified activities were validated against another existing study [35] and positioned on a timeline. Subsequently, we mapped the activities against the available description of the Product Owner role in SAFe, and an overview of the mapping results is provided.

3.2.1. Generic Concept of the Product Owner Activities

Jeff Sutherland did the first implementation of Scrum in the software development context at Easel Corp in 1993 [31]. This was the moment when the Product Owner role was created [33]. In the 1990s, the Product Owner was referred to as the person responsible for managing the Product backlog to maximize the value of the project. The role represented all stakeholders in the project [28]. Cohn [31] stated that the Product Owner role was usually fulfilled by Product Managers, Marketing, Internal Customers, etc. According to Schwaber [28], key customers were stepping into the role of Product Owner. Schwaber [28] was the first who described the role in more detail. According to Schwaber [28], the main activities of the Product Owner can be expressed as follows: (1) represent all stakeholders in the project; (2) maximize the return on investment; (3) cooperate with team sprint by sprint; (4) define the highest priority business value; (5) create release plans; (6) create initial requirements; (7) prioritize the Product backlog; and (8) explain the value during the team meetings. The importance of the Product Owner role was emphasized by Raithatha [45], and more research papers and publications related to the Product Owner role later followed. During our literature review, we identified and extracted the Product Owner activities. All extracted activities are listed, including the reference to the source publication, in

Table 1. Backlog category and activity mapping to the Product Owner role description in SAFe.

ID	Activity	In SAFe?	Comment
(BA1)	Prioritize Product backlog [28]	No	The Product Manager is the person with Product backlog content authority and is accountable for the prioritization. The Product Owner (PO) has the content authority for the team’s backlog and prioritizes requirements to be developed by the agile team.
(BA2)	Create initial requirements [28]	No	The Product Manager defines the features. The PO defines the user stories that lead to the completion of the feature, as well as the stories to capture results from the iteration reviews.
(BA3)	Make backlog available and visible to everyone [46]	No	The PO is the single person responsible for the Team backlog, but there is no requirement stated that the backlog has to be available and visible to everyone.
(BA4)	Maintain and sustain a single Product backlog [24]	No	The Product Manager maintains the Product backlog. The PO maintains and sustains the single Team backlog, which can be understood as a subset of the Product backlog.
(BA5)	Clearly express Product backlog items [47]	Yes	The PO ensures each iteration goals are clearly defined and communicated, and that the team has a clear connection to the business.
(BA6)	Order the items in the Product backlog to best achieve goals and missions [47]	Partially	The PO orders the items in the Team backlog to best achieve the Program Increment objectives and contribute to the creation of features requested by the Product Manager, who is the person driving the direction of the product.
(BA7)	Ensure that Product backlog is visible, transparent, and clear to all [47]	No	The PO regularly meets with Product Management members and stakeholders to update them about the changes in the scope. However, there is no requirement to ensure that the backlog is visible, transparent, and clear to all defined.
(BA8)	Ensure the Development Team understands items in the Product backlog [47]	Yes	The PO has to ensure the team is aligned to the Program Increment (PI) objectives, presents and explains stories during iteration planning, and represents the customer needs to the team.
(BA9)	Describe requirements [29]	Yes	The PO writes stories or collaborates with others on their creation to capture the requirements. The PO also ensures all work to be addressed by the agile team is captured in the Team backlog.
(BA10)	Make sure the Product backlog is continuously evolving [15]	Partially	The PO verifies the stories contain valid information, contain acceptance criteria, and are in line with the vision. The PO attends product management meetings for program backlog refinement.
(BA11)	Elicit requirements [48]	Partially	The PO is responsible only for the requirements represented by stories in the Team backlog. The elicitation in SAFe is a complex process taking place at all levels (Portfolio, Program, Team).
(BA12)	Prioritize and reprioritize requirements [48]	Partially	The Product Manager has the authority to prioritize features, and Architects have the authority to prioritize enablers at the program level. The PO only prioritizes stories and enablers in the Team backlog to meet the priorities set by the Product Manager.
(BA13)	Refine the backlog [27]	Yes	The PO regularly meets with the team to refine the Team backlog and to slice stories and enablers into smaller parts.
(BA14)	Define acceptance criteria [27]	Yes	The PO defines the acceptance criteria for the stories or verifies that the stories contain them and align with the vision and scope.
(BA15)	Balance technical and business issues [27]	Yes	The PO includes prioritization of enablers, which are mostly technical tasks, based on collaboration with system architects.

,

Table 2. Project category and activity mapping to the Product Owner role description in SAFe.

ID	Activity	In SAFe?	Comment
(PA1)	Maximize the value of the project [31]	Yes	The PO has a critical role in the maximization of the value produced by the team.
(PA2)	Maximize the Return on Investment (ROI) [28]	Partially	The Product Manager owns the ROI and defines features to maximize it. The PO contributes to the maximization of the ROI through prioritization of stories and enablers for agile teams.
(PA3)	Create release plans [28]	No	The Product Manager defines releases, program increments, and business objectives. The PO, as the extended product management, can impact the plan, but has no authority or ownership of the releases.
(PA4)	Make fast and prevailing decisions [24]	No	Aside from the decisions on the priorities and capacity allocations, there were activities describing the need for fast and prevailing decisions identified for PO in SAFe.
(PA5)	Steer the project [29]	Partially	The PO helps drive PI Objectives on the Team Level and plans the iteration goals, but the steering does not take part in role description in SAFe.
(PA6)	Manage economics [29]	Partially	Economics in SAFe should drive decisions on all levels; therefore, even the PO has to take an economic view while deciding about the Team backlog’s priorities. However, the overall economics of the project, product, or solution is not in the scope of PO activities.
(PA7)	Ensure project compliance with corporate guidelines and policies [15]	No	There was no description found prescribing this kind of activity of PO in SAFe.
(PA8)	Perform risk management and mitigation [15]	No	There was no description found prescribing this kind of activity of PO in SAFe.
(PA9)	Keep global teams in sync [15]	Yes	The PO meets weekly with other POs during PO sync to provide visibility into the progress toward set objectives, discuss problems opportunities, and remove dependencies.
(PA10)	Decide about features going live [48]	No	The Product Manager has authority over features and their releases.
(PA11)	Participate in planning [27]	Yes	The PO attends the planning with the product management. The PO leads the iteration planning. During the iteration planning, the PO, together with the team, selects the highest-priority items to be implemented in the iteration.
(PA12)	Process improvement [49]	Partially	The PO participates in iteration retrospective, where the team identifies ways to improve their processes and inspect and adapt workshops. However, no direct responsibilities during the actual conduction of process improvement were identified.
(PA13)	Develop business/Product plan [49]	No	The roadmaps, pricing, and licensing are owned by the Product Manager. The business strategies and plans are developed on the solution and portfolio levels of SAFe.
(PA14)	Develop service planning [49]	No	SAFe has dedicated roles inside so-called Shared Services to cover this kind of activity. The PO is not involved. The Product Manager should cover additional partnership with service partners.
(PA15)	Manage governance [17]	No	There was no description found prescribing this kind of activity of PO in SAFe. Managing governance is a responsibility of other roles i.e., Release Train Engineers, Scrum Masters, or System Architects.

,

Table 3. Customers and Business category and activity mapping to the Product Owner role description in SAFe.

ID	Activity	In SAFe?	Comment
(CA1)	Represent stakeholders [28]	Yes	The PO represents the voice of the stakeholders and customers to the team.
(CA2)	Provide a vision [24]	No	The Product Manager sets the vision for the agile release train (on a program level), and the PO makes sure the user stories prioritized for the team ale aligned with the vision.
(CA3)	Communicate and negotiate with stakeholders to avoid conflicts [19]	Partially	The PO regularly meets with other POs during sync meetings to align on the progress. The PO helps to identify the potential conflicts and dependencies during the PI planning. The PO escalates any obstacles to the Product Management.
(CA4)	Manage expectations of different stakeholders [38]	Partially	The PO works with the Product Management to identify and plan Program Increments and reflect various stakeholders’ ideas and requirements. However, the main expectations and directions are directed from the Product Manager in the form of features and enablers.
(CA5)	Gather requirements from clients [15]	Partially	Product Manager is a customer-facing role responsible for gathering requirements and reflecting them in the features. The PO only reflects the ideas and feedback gathered during the iteration review.
(CA6)	Represent the ideas and needs inwards and outwards the organization [39]	Partially	The PO represents the needs of customers to the team, as well as actively participates in iteration reviews and system demos. However, the PO is mostly a team-facing role, and external communications are the Product Manager’s responsibility.
(CA7)	Manage customer relations [48]	No	The Product Manager (PM) is a customer-facing role responsible for managing the customer relations with the support of other SAFe roles.
(CA8)	User support [49]	No	SAFe has dedicated roles inside so-called Shared Services to cover this kind of activities. The PO is not involved. Collaboration with the support team is expected, but no direct involvement in support activities was identified.
(CA9)	Provide domain and business expertise [27]	Yes	The PO is supposed to have good domain knowledge and business sense.
(CA10)	Collaborate with stakeholders [27]	Yes	The PO works with the product management and other Product Owners in the agile release train, as well as interacts with the internal stakeholders and organizational management. The PO mainly collaborates with the Product Manager, Release Train Engineer, System Team, and Business Owners.
(CA11)	Manage stakeholders [50]	Partially	Stakeholder management is the shared activity between the PO and PM.

,

Table 4. Team category and activity mapping to the Product Owner role description in SAFe.

ID	Activity	In SAFe?	Comment
(TA1)	Cooperate with team sprint by sprint [28]	Yes	The PO regularly participates in all team events and should ideally be collocated with the teams.
(TA2)	Motivate the team/s [45]	No	There was no description found prescribing this kind of activity of PO in SAFe.
(TA3)	Find ways how to get team more involved into project [45]	No	There was no description found prescribing this kind of activity of PO in SAFe.
(TA4)	Be available and engaged with the team [24]	Yes	The PO is collocated with the team and available each day to answer questions and clarify stories, as well as being responsible for actively contributing to all team events.
(TA5)	Resolve conflicts [19]	No	There was no description found prescribing this kind of activity of PO in SAFe.
(TA6)	Lead people [39]	No	There was no description found prescribing this kind of activity of PO in SAFe.

and

Table 5. Development category and activity mapping to the Product Owner role description in SAFe.

ID	Activity	In SAFe?	Comment
(DA1)	Design, implement and disseminate a reference architecture [15]	No	The PO is only supposed to understand the scope of the architectural works coming to the team. Outside of prioritizing this type of work for the team, there is no evidence that they implement or disseminate reference architecture.
(DA2)	Test of development outcomes [48]	No	There was no description found prescribing any PO involvement in the conduction of the testing.
(DA3)	Define test criteria for requirements [48]	Yes	The PO collaborates with the team to create acceptance criteria and examples in the form of acceptance tests.
(DA4)	Verify completion of requirements [27]	Yes	The PO accepts the iteration increments in the form of stories by validating acceptance criteria, assuring a level of quality and fitness for use.

in the column “Activity”.

3.2.2. Validation of Product Owner Activities

The reliability of the findings and the correctness of the literature review were validated through comparison with the study on Product Owners in industry [35]. In this study, the research team at Leibniz University Hannover did a mapping study on Product Owners in industry to identify future research directions. The study combined the Product Owner role from Scrum and the on-site customer role from Extreme programming. As one of the outcomes, they listed the Product Owner activities identified during the mapping study. These activities are listed in the “Product Owners in industry study” [35] column in

Table 6. Activities mapping to the Product Owners in industry study [35].

Our Study	Product Owner in Industry Study
CA3, PA9	Communication
BA5, BA9	Writing user stories
PA11, PA13, PA14	Planning
BA1, BA6, BA12	Prioritize the backlog
PA3	Mastering the release
DA1	Technical architect
PA7, PA15	Governor
CA5	Traveler
CA1, CA3, CA9	Intermediary
PA8	Risk Assessor
PA10	Gatekeeper
DA2	Acceptance tester
CA7, CA11	Customer relationship manager
CA4	Managing expectations
CA3, CA4	Political advisor
--	Super secretary
CA2	Visionary
--	Accountability
TA1, TA4	Teamwork
--	Expert trainer
PA4	Critical decision-maker

and are mapped to the activities identified in our study, represented by their identifiers (IDs), in the “our study” column. The IDs are from Table 1, Table 2, Table 3, Table 4 and Table 5, where each activity’s description is provided in column 2. Each table represents one category created as per Section 3.2.3.

The result of the mapping confirmed that nearly all activities from the study on Product Owners in industry [35] have corresponding activities identified by the authors. The only exceptions were the super secretary and expert trainer. The reason is that the activities came from papers not related to the Product Owner role, but the on-site customer role from Extreme programming, which was not considered in our study. For “accountability”, no equivalent was identified as the activity definition is very vague. As the remaining activities or their equivalents were identified in our study, this advocates for not missing any important activities and, therefore, the reliability of the study.

Comparison of our research objectives (OBJ1 and OBJ2) and the Product Owners in industry study [35]. (1) Our focus was specifically on the extraction of the Product Owner activities. (2) The on-site customer from Extreme programming was not considered in our search. (3) We included practitioners’ books. (4) The activities were extracted with the consideration of the date of their appearance. (5) We followed the content analysis process during the activities extraction and categories creation [34]. (6) The main intention of activity extraction was to build a strong foundation for further mapping to SAFe. It resulted in the identification of 22 additional activities not presented in the Product Owners in industry study [35]: (BA3)—Make backlog available and visible to everyone, (BA4)—Maintain and sustain a single Product backlog, (BA7)—Ensure that the Product backlog is visible, transparent, and clear to all, (BA10)—Make sure the Product backlog is continuously evolving, (BA11)—Elicit requirements, (BA13)—Refine the backlog, (BA14)—Define acceptance criteria, (BA15)—Balance technical and business issues, (PA1)—Maximize the value of the project, (PA2)—Maximize the Return on Investment (ROI), (PA5)—Steer the project, (PA6)—Manage economics, (PA12)—Process improvement, (PA13)—Develop a business/Product plan, (TA2)—Motivate the team/s, (TA3)—Find ways how to get the team more involved in the project, (TA5)—Resolve conflicts, (TA6)—Lead people, (CA8)—User support, (CA10)—Collaborate with stakeholders, (DA3)—Define test criteria for requirements, and (DA4)—Verify completion of requirements. The cause seems to be twofold. (1) The Product Owners in industry study [35] did not focus specifically on the Product Owner role activities, as its main goal was to identify areas requiring further research; hence, the search and extraction of activities from different publications were not that thorough. (2) During the conduction of the Product Owners in industry study [35], no books written by consultants from the practice were included. On the contrary, in our research, books [24,25,26,27,28,29,30] were included, which provided a new resource for identification of more activities and contributed to the extension of the list of activities.

3.2.3. Categories of the Product Owner Activities

To better understand changes in multiple areas of the Product Owner activities, it was advisable to categorize them. Therefore, five different categories of activities were defined: Backlog, Project, Team, Customers and Business, and Development. The Backlog category was derived from the definition of backlog management from the Scrum Guide [46]. As the Product Owner was responsible for maximizing the value of the project since the first introduction of the role [28,31], Project was used as one of the categories. The Team was identified as another category because of the described need for cooperation with the development team [28]. The Product Owner has to represent customers [28] and deeply understand the business [24]. These two areas are closely related; therefore, the joint category Customers and Business was created. With the Product Owner’s direct involvement in the development process [15,27,48], a new set of activities emerged. Therefore, the Development category was introduced.

As the next step, all extracted activities were organized into created categories. We present the results in Table 2, Table 3, Table 4, Table 5 and Table 6, with one table for each category. Within the categories, the activities are chronologically ordered. In the first column of the table, we introduce an activity ID for further use in this paper. The second column contains the extracted activity with a reference to the publication where activity was recognized for the first time. The last two columns are dedicated to the mapping of the activity to SAFe description of the Product Owner role.

3.2.4. Product Owner Activities Timeline

All identified activities were positioned on a timeline to provide a view of the change through the lens of time, better understand how the role had been evolving as the Agile gained more popularity, and lay a foundation for the discussion provided in this paper. The Product Owner activity timeline is depicted in Figure 1. The timeline starts with 1995 as the year when the Scrum method, including the Product Owner role, was introduced to public [4]. Due to the absence of Product Owner activity descriptions in materials before [31], there were no activities positioned on the timeline before the year 2003.

For the activities in the Backlog category (BAn), there was a visible shift identified from setting the initial requirements and giving them a priority (BA1, BA2) to providing a more detailed specification (BA9, BA11, BA14), including acceptance criteria and continuous backlog evolution (BA10, BA12, BA13).

The Project activities (PAn) in the timeline indicate that, since the beginning, the Product Owner had to maximize the value of the project (PA1, PA2). To do so, the Product Owner needed to start making important decisions (PA4), steer the project (PA5), manage its economics (PA6), and decide about features to be released (PA10), while following plans (PA13, PA14).

The need for close team collaboration [2] was proven for the Product Owner by activities (TAn) falling under the Team category. The Product Owner activities in the category evolved from simple cooperation with the team (TA1) through the activities related to the team’s motivation and involvement (TA2, TA3), solving conflicts (TA5), and leadership (TA6).

The Customer and Business category’s Product Owner activities were initially supposed to be performed by key customers [28], who represented all stakeholders to the development team (CA1). Results show that it changed to the activities of an employee who needs to provide a vision (CA2) and manage stakeholder’s expectations (CA4). User support (CA8) appeared as a new unique activity.

The results show that the adoption of Agile in large organizations [7,9] brought about new sets of activities, mostly visible in the Customers and Business and Project categories. The Product Owner should gather requirements (CA5), present ideas and needs both inward and outward the organization (CA6), and collaborate with stakeholders (CA10). The Product Owner also should ensure compliance with the corporate guidelines (PA7), align more development teams together (PA9), participate in company-wide planning (PA11), focus on process improvement (PA12), and manage the governance (PA15).

The development-related activities first appeared in 2015; therefore, they were considered the newly emerged category of activities tied to the role of evolution with increasing adoptions. The Product Owner became involved in designing, implementing, and disseminating a reference architecture and providing an architecture on large projects (DA1). It was also reported that the Product Owner directly participates in the execution of test activities by testing development outcomes (DA2) or defining test criteria for specified requirements (DA3). The Product Owner also concludes the development process by verifying the completion of requirements (DA4).

3.2.5. Mapping of the Product Owner Activities to SAFe Product Owner Role Description

The descriptions of Product Owner activities in SAFe were analyzed and mapped to the generic concept of Product Owner activities created in step 8. The results are presented in Table 1, Table 2, Table 3, Table 4 and Table 5. For each activity, in the third column, we provide information of the presence in SAFe with the following possible values: “No”—activity or similar was not identified as part of the Product Owner role in SAFe; “Yes”—activity was identified as prescribed for Product Owners in SAFe; “Partially”—some similarity to the identified activity was discovered; however, the activity’s full scope from the generic concept of Product Owner activities is not fulfilled by the Product Owner in SAFe. Each result is complemented with a brief commentary to support the stated value.

3.2.6. Mapping Overview

To better depict which activities were discovered and verified to be included in the prescription of the Product Owner activities in SAFe, we provide an overview in Figure 2. The overview was built on the findings presented in Table 1, Table 2, Table 3, Table 4 and Table 5. The activities positioned on the border of the circle with the activities discovered in SAFe are those we identified as performed only partially. Then, we discuss the results and differences regarding each of the previously defined categories of Product Owner activities and the context of SAFe.

The difference in the Backlog category seems related to fragmentation of the activities and backlogs in SAFe. The concept of a single Product backlog is replaced with the Program backlog, owned by the Product Manager (PM), and the Team backlog, owned by the Product Owner. The Team backlog represents a program backlog subset and contains all requirements assigned to the team, not the whole product. Therefore, the Product Owner in SAFe no longer has full authority over the product. The Product Owner can affect the Product Manager’s decisions, but the PM is the person driving the product and the product’s true owner. Hence, the set of activities from the Backlog category valid for the Product Owner in SAFe is reduced. The Product Owner in SAFe is mostly the team-facing role, and the found activities are aligned with it. The Product Owner’s main focus is on the clarity of the Team backlog items. After the Product Owner drafts the requirements (BA11) on the basis of priorities coming from the Program Backlog into user stories (BA9), they have to be communicated to the team (BA5). After making sure the development team understands them (BA8), the Product Owner collaborates with the team to refine requirements into smaller deliverables (BA13) with clearly stated acceptance criteria (BA14). When the requirements are understood and stories are properly defined, the Product Owner orders the Team backlog items to best meet the team’s objectives (BA6). It is necessary to balance technical and business requirements (BA15) and prioritize them on the basis of the current team capacity during this process. This process is repeated every iteration, and priorities change (BA12). Yet, all these activities are related to the Team backlog only.

The fragmentation of activities is also visible in the Project category. One of the key Product Owner responsibilities, which is the maximization of the project’s value (PA1), is present in SAFe. However, the Product Owner has a critical role in maximizing the value produced by the team and the Product Manager for the value of the product. The Product Manager also owns the ROI and features, while the Product Owner contributes to the maximization of the ROI (PA2) through the prioritization of requirements for the development team. SAFe prescribes economics to drive decisions on all levels; therefore, the Product Owner contributes to the management economics (PA6). Yet, managing the project’s overall economics, product, or solution was not identified to be in the scope of Product Owner activities. Compared to the generic concept of Product Owner activities in the Project category, the Product Owner responsibilities in SAFe do not cover release management, make fast decisions, ensure compliance with the corporate guidelines, manage governance, or develop the business or product plans. Nevertheless, the Product Owner in SAFe has to participate in planning sessions (PA11) on both the team and the program levels, as well as keep the global teams in sync (PA9). The Product Owner contributes to the improvement of processes (PA12) but has no direct responsibilities to enforce the improvements prescribed.

Despite the Product Owner being a team-facing role, we identified only two activities from the Team category to be present in SAFe. First, the Product Owner is collocated with the team and, as the representative of the customer’s needs toward the team, is available to answer questions and clarify the stories (TA4). Second, close collaboration with the teams (TA1) includes active participation in all team events. The managerial and leadership activities discovered during the literature review and assembling of the generic concept of the Product Owner activities were not discovered during the analysis of SAFe.

The Product Owner in SAFe remained the representative of various stakeholders toward the team (CA1). However, some of the activities identified for Product Owners in the Customers and Business category are performed by the Product Manager. The Product Manager sets and owns the product vision, acts as a customer-facing person, manages the customer relations with the help of other SAFe roles, and creates features on the basis of the clients’ requirements. The Product Owner contributes and collaborates with the PM to identify and plan Program Increments and reflect various stakeholders’ ideas and requirements (CA4). Nevertheless, they are directed by the Product Manager in the form of features. The ideas are then presented inward and outward the organization (CA6), where the Product Owner and Product Manager share the responsibilities. The Product Manager is more customer- and outward-oriented, while the Product Owner communicates the ideas inside the organization. The Product Owner closely collaborates with many stakeholders i.e., Product Manager, Release Train Engineer, System Team, Business Owners, and other Product Owners (CA10). The Product Owner is supposed to have good domain knowledge and bring the business sense into the agile team (CA9).

With regard to the Development category, the Product Owner activities in SAFe are narrowed to the definition of test criteria for requirements (DA3). The Product Owner collaborates with the team on the creation of acceptance criteria and examples in the form of acceptance tests. Next, the Product Owner verifies the completion of requirements through the acceptation of iteration increments (DA4). No direct involvement in testing or providing any kind of architectural inputs has been identified.

4. Discussion

In this paper, the evolution of the Product Owner activities since the first introduction of the role until its adoption to SAFe was described. Evidence was provided that, as Agile has spread through the industry [3,6,7,9], the Product Owner role has changed from a relatively simple role that was meant to be covered by customer representatives or internal stakeholders [31] to a more complex role covering a wide range of activities.

Some of the Product Owner activities were previously listed in the study on Product Owners in industry [35]. Compared to the study on Product Owners in industry [35], this paper’s specifics were as follows: (1) focused the area of the Product Owner activities only; (2) provided the view on the evolution of the Product Owner activities through the lens of time; (3) depicted the activities in the context of SAFe. The useful value was in providing concrete specifics and a detailed view on the role difference in SAFe. These specifics must be understood by enterprises when seeking eligible candidates for the Product Owner role and the candidates applying for the Product Owner role.

It is visible that the same factors, such as organizational culture, project type, and management approach, described by [38] as impacting the success of Product Owner, also affect the set of activities the Product Owner performs. Our study supports the findings [37] that it cannot be explicitly defined what the Product Owner activities generally are. Organizational and context specifics of the role are the cause of ambiguity. The results show that, with the adoption of Agile in large organizations [7,9], new kinds of activities were identified for Product Owner. However, during the examination of the Product Owner role in SAFe, the framework for scaling Agile, the presence of all the activities described in existing publications was not confirmed.

The mapping of Product Owner activities to the role description in SAFe revealed the fragmentation of the Product Owner activities into multiple roles. This fragmentation of the Product Owner role is consistent with findings in [17] that, on a large scale, the scope of activities goes beyond the capacity of one person acting as a Product Owner. Close collaboration between the Product Owner and PM described in [14] was confirmed. The decisions about product priorities and requirements for development are set by the Product Manager. This Product Manager activity contradicts the Product Owner’s prime Scrum definition [46] as the sole person responsible for managing the Product backlog.

Interestingly, in the newest version of the Scrum Guide from 2020 [36], the “sole person’s responsibility” has been removed from the Product Owner role definition. This removal conforms with the necessary evolution of methods [8]. The mapping showed that the evolution and the Product Owner’s role journey to SAFe led to the removal of the Product Owner’s real product ownership. In SAFe, the real Product Ownership lies in the hands of the Product Manager. A similar conclusion was presented in the preliminary outcomes from the empirical research in [42]. This is caused by introducing additional horizontal structures that enable the top-down managerial approach in SAFe [43]. The Product Owner in SAFe is still an important role that directly impacts the success of projects, similar to the previously identified importance of the role in large-scale environments [9]. However, the range of activities is narrowed down to the team level.

The importance of frequent communication and interaction between Product Owners in large-scale Agile [18] applies to SAFe. The need for close team collaboration [2] is evident. However, no managerial or leadership activities regarding the team were discovered [35]. A similar concept applies to product leadership, where the activities are owned and executed by the Product Manager. The Product Owner seems only to be responsible for driving and overseeing the execution of requirements defined in the Product Manager’s features.

Companies seeking suitable candidates for the Product Owner role in the SAFe environment have to consider the role specifics in SAFe. Instead of looking for a skilled product leader, a team-oriented person is needed. The Product Owner in SAFe has a different role compared to what was described for Product Owners in the past. Hence, different sets of skills are required. Additional research is needed to better understand the right characteristics and skills of good fits for the Product Owner position in SAFe. Additionally, to help organizations staff the right Product Owner, it is recommended to research if Product Owners coming from organizations not following SAFe are good candidates for the Product Owner role in SAFe, or if enterprises should consider people with different experience and background. Lastly, more empirical research on Product Owner in SAFe is needed.

5. Conclusions

By conducting a literature review to identify activities typical for Product Owners outside the context of Scaled Agile Framework (SAFe), and by mapping these activities to Product Owner role description in SAFe, we revealed the evolution of the Product Owner role in terms of time and role specifics in SAFe. The changes are connected to the increasing adoption of Agile by various types and sizes of organizations, scaling of agile methods, and their tailoring. The mapping of the identified activities to the descriptions of SAFe showed a significant difference in the scope of activities expected to be performed by the Product Owner role in SAFe. The original concept of the Product Owner’s role covering the whole range of activities identified during the literature review is clustered into multiple roles in SAFe. SAFe clearly distinguishes between the Product Manager and Product Owner and distributes the activities among the roles. In fact, the Product Manager has real product ownership, while the Product Owner is responsible for driving and overseeing the implementation of the requirements. We can, therefore, conclude that, in the large environments for which SAFe is designed, it is impossible to cover all required activities by one role using the hierarchical structures with a top-down approach in SAFe.

The following scientific contributions were made: (1) list of the generic Product Owner activities enhanced; (2) Product Owner activities categorized; (3) timeline representing the evolution of the Product Owner activities created; (4) activities performed by the Product Owner in SAFe identified.

The following applied contributions were made: (1) difference in the core concepts of the Product Owner role in the context of SAFe articulated; (2) requirements to the people assigned to the Product Owner role in SAFe more clearly recognizable; (3) enterprises being able to leverage results to overcome the challenge with staffing the right Product Owners.

Further research should investigate the following: (1) identification of the concrete skills and competencies of the Product Owner in SAFe; (2) determination if Product Owners coming from organizations not following SAFe are good candidates for the Product Owner role in SAFe; (3) empirical research on the Product Owner role in SAFe.