Content uploaded by Carolin Unger-Windeler
Author content
All content in this area was uploaded by Carolin Unger-Windeler on Apr 30, 2019
Content may be subject to copyright.
©IEEE. PREPRINT. This is the authors version of the work. It is posted here by permission of IEEE
for your personal use.Not for redistribution. The definitive version was published in the
conference/workshop proceedings.Refer to the paper using:to be updated once doi available.
A Mapping Study on Product Owners in Industry:
Identifying Future Research Directions
Carolin Unger-Windeler
Leibniz Universit¨
at Hannover
Software Engineering Group
Germany
carolin.unger-windeler@inf.uni-hannover.de
Jil Kl¨
under
Leibniz Universit¨
at Hannover
Software Engineering Group
Germany
jil.kluender@inf.uni-hannover.de
Kurt Schneider
Leibniz Universit¨
at Hannover
Software Engineering Group
Germany
kurt.schneider@inf.uni-hannover.de
Abstract—Product Owners in the Scrum framework – respec-
tively the On-site Customer when applying eXtreme Program-
ming – have an important role in the development process.
The Scrum Guide states that this role is responsible for the
requirements and maximizing the value of the product. However,
the implementation of this role depends on the individual, the
organization and the team and is perceived as difficult in industry.
Various research approaches provide insights in the applied
PO role in industry – yet, a conclusive bigger picture of the
studies and reports on this issue is missing. To fill this gap, we
conducted a systematic mapping study. Our findings structure the
research area of Product Owners in industry in terms of research
topics and applied research methods.
In total, we identified 30 contributions addressing seven
research topics and generated consolidated answers for each of
them. While some of those topics provide congruent results, oth-
ers point to gaps in current research: So is the PO role in large-
scale projects clearly defined as a group effort, but questions
regarding the leadership and management responsibilities of POs
remain unanswered.
Also, the impact of external circumstances on the PO role is
a question that is worth to answer in future work.
Index Terms—Product Owner, On-site Customer, Agile Soft-
ware Development, Scrum, XP, Systematic Mapping Study
I. INTRODUCTION
Nowadays, it is a competitive advantage to develop and
distribute high-quality software at a high pace [14]. Especially
in a system development environment working software needs
to be delivered at an early stage while it remains flexible
and adaptable to changes [14]. Agile software development
addresses those needs and promises to satisfy them [5, 8, 22].
Consequently, a lot of companies strive towards a more agile
development approach [19]. However, especially in traditional,
top-down system development organizations, integrating agile
methods and practices is often reported as difficult [6]. In this
domain, becoming agile often goes along with fundamental
changes that are facing a lot of barriers [6]. Boehm and
Turner [6] identified three areas that are critical challenges for
software managers to successfully integrate agile methods and
practices in their projects: (1) development process conflicts,
(2) business process conflicts, and (3) people conflicts whereas
the people issues are at the heart of the agile transformation. In
this contribution, we consider the people issue at the level of
On-Site Customer or Product Owner as they have an important
role in the development process.
In eXtreme Programming (XP), the on-site customer is a
person who knows the domain well, is able and responsible
for making business decisions and to be on-site with the rest
of the XP team [29]. Beck [4] defines an on-site customer to
be “a role on the team for choosing what stories the system
has to satisfy, what stories are needed first and what can be
deferred” [4, p. 177]. In the Scrum framework, the role of a
Product Owner (PO) is represented by a single person who is
responsible for requirements elicitation and for requirements
prioritization [38, 37]. According to Schwaber [37], a PO has
to maximize the value of the product developed by the team.
However, he does not propose how to do this. Instead, he
clearly states that “how this is done may vary and depends
on the organization, team structures and individuals” [37].
For large scale scrum, Larman and Vodde [23] define the
PO as a group of POs and not as a single person. A team
of POs meets the responsibilities and tasks of a single PO,
possibly with a hierarchical structure. One of the PO team
members works as the chief product owner and has the final
decision for assignments and prioritization [23]. Leffingwell
[24] proposes a steering committee with Uber-product owners
that meet weekly.
These definitions draw a very comprehensive picture of
tasks and responsibilities of POs and On-Site Customers. This
coincides with our experiences from industry [41]. As a first
step towards a definition of these roles, we want to gain an
overview of existing literature. We are interested gaining an
overview of the aspects of the role of product owners that have
been addressed by researchers.
To meet this goal, we conducted a systematic mapping study
including insights from 30 publications. Our results provide
a conclusive bigger picture of the literature on the Product
Owner – respectively the On-site Customer1– role in industry.
We identified that current research addresses seven research
topics: (1) scaling the PO role, (2) functions, challenges
& responsibilities, (3) leadership / management, (4) success
factors, (5) theory vs. practice, (6) requirements engineering,
(7) collaboration / involvement. Based on the mapping study,
we identify gaps in current literature such as the neglect of
requirements engineering practices of POs and the leadership
and management responsibilities.
The rest of this paper is structured as follows: Section II
presents related work. In Section III, we describe the method
used for the systematic mapping study. In Section IV, we
report and map the review of the literature. In Section V, we
discuss our findings. Section VI concludes our work.
II. RE LATE D WORK
Agile methods and their roles are in place for almost
two decades. In 2005, Boehm and Turner [6] reported that
in industry agile practices are perceived less burdensome
on small, stand-alone projects than in traditional, top-down
systems development organizations. They identified the most
critical challenges for software managers and categorized them
as development process conflicts, business process conflicts
and people conflicts. To overcome these conflicts eventually,
they highlight the importance of research and experience
reports to capture data on those areas [6]. Hence, we expected
that there has been a variety of publications addressing the
important role of the Product Owner in the area of people
conflicts. Surprisingly, there are only few contributions on this
topic.
Bass et al. [2, 3] provide insights in the topic of POs.
Their qualitative study of software engineering practice com-
prised eight international companies and interviews with 45
practitioners [2]. They identified actual performed tasks and
activities of Product Owners in large enterprises. They re-
ported the following nine Product Owner team functions:
groom, prioritizer, release master, technical architect, governor,
communicator, traveler, intermediary and risk assessor. These
functions arbitrate between conflicting customer requirements,
approving release schedules, disseminating architectural de-
sign decisions, providing technical governance and propagat-
ing information across teams [2]. In a more recent study Bass
et al. [17] also compared these functions to actual tasks and
activities of POs in small companies and identified differences
indeed. Unger-Windeler and Kluender [41] conducted a case
study in the oil and gas industry to check whether these
nine Product Owner functions are performed there as well.
Preliminary results indicate that the tasks differ and that not
only the size of the company, but the organizational structure
might has an impact on the Product Owners role as well.
1In order to improve readability, we always refer to both roles even if only
the Product Owner role is mentioned.
Considering these works, the role of the Product Owner
is influenced by multiple factors. However, there seem to
be several scattered results on the role of a PO, but there
is no conclusive bigger picture of the studies and reports as
there is neither a literature review nor a mapping study that
structures this research area. Consequently, there is a clear
need for a mapping study considering the role of the PO in
order to structure this research area, to identify potential gaps
in existing literature as well as to define prospective research
topics regarding these roles.
III. RESEARCH DESIGN
To meet our goal and achieve an overview of aspects
regarding the role of POs that have already been addressed
by researchers, we conducted a mapping study. This method
primarily enables to structure a research area and to identify
gaps and possibilities for future research [33, 34]. In addition,
a mapping study allows to gain a wide overview of the research
area [18]. The research process described by Petersen et al.
[34] served as a basis for our research and will be described
in this section. However, we have modified this process by
adding the step of snowballing search as visualized in Figure
1. By including this step, we achieved a more comprehensive
list of relevant papers.
Fig. 1. Modified Research Process
A. Research Questions
In contrast to systematic reviews where a very specific goal
has to be formulated, the research questions in mapping studies
are more general as they aim to discover research trends [33].
The main research question we want to answer with this
mapping study is:
RQ: Which aspects of the role of Product Owners
and On-site Customers in industry have been subject to
research?
In particular, we are interested in answering the following
subquestions:
RQ 1: What research topics regarding the Product Owner role
in industry are addressed in research?
RQ 1.1: What research method was applied to answer their
research questions?
By answering these questions, we want to gain an overview
of the current status of this research area. This questions helps
us to classify and structure the research area.
RQ 2: What insights about Product Owners are presented in
research?
To get the maximum value out of this research, we want
to preserve and summarize the knowledge shared in the
considered publications. We will structure the content based
on the addressed research topics identified in RQ1.
RQ 3: What external circumstances of the Product Owners’
environment have been analyzed in research?
While practitioners have an increased interest in tailoring
agile software methods to large scale offshore enterprise
development programs [24, 23, 1], a co-located development
team with approximately nine members is ideal to work with
[37]. Hence, we were interested in whether these external
circumstances are considered in current research. In particular,
we want to analyze current literature with respect to the
following aspects which are part of the environment.
RQ 3.1: What organizational structures are considered in
literature?
RQ 3.2: What company sizes are considered in literature?
RQ 3.3: What team dimensions are considered in literature?
RQ 3.4: What team locations are considered in literature?
B. Research Method
This section describes the process followed to conduct the
search according to Petersen et al. [34].
a) Defining the search string: The keywords were identi-
fied using PICO (Population, Intervention, Comparison, Out-
comes) [18]. The PICO criteria were developed to identify
keywords and formulate search strings from research questions
[33].
Population: Population may refer to specific software en-
gineering role or a category of software engineer [33]. In our
context, the population are defined by Product Owners and
On-site Customers in industry.
Intervention: In software engineering, intervention may
refer to a software methodology [33]. In the context of this
study, we investigate on the intervention of two agile software
development methods: Scrum and eXtreme Programming.
Comparison: This is the software engineering methodology
the intervention is compared to [18]. We do not compare
two methodologies, but we rather compare findings of current
research with regards to research topics addressed in literature
(RQ1), the key findings (RQ2) and the environment (RQ3).
Outcomes: Outcomes should relate important factors such
as reduced production costs or reduced time to market [18]. In
our context, we expect measurable results in terms of research
gaps or saturations.
Combining these considerations, we identified the keywords
Product Owner,Industry and Agile. For these three keywords,
we used the synonyms and abbreviations shown in Tab.I.
TABLE I
OVE RVIE W SE ARC H KE YW ORD S
Search keyword 1 ”Product Owner(s)”
Abbreviation ”PO(s)”
Related keywords ”On-Site Customer(s)”
”Product Manager(s)”
Search keyword 2 ”Industry” / ”Industries”
Related keywords ”Organization(s)”
”Practice”
Search keyword 3 ”Agile”
Related keywords ”Scrum”
”eXtreme Programming”
Abbreviation ”XP”
The keywords were used to formulate the search string:
(”product owner” OR ”product owners” OR ”PO” OR
”POs” OR ”product manager” OR ”product managers” OR
”on-site customer” OR ”on-site customers” )
AND (”industry” OR ”industries” OR ”organization” OR
”organizations” OR ”practice”)
AND (”agile” OR ”scrum” OR ”extreme programming” OR
”xp”)
b) Selection of Databases: Seven databases have been
selected for the mapping study: ACM Digital Libraries,
Springer Link, Science Direct, IEEE, Google Scholar, Wiley
Online Library and Scopus. With these databases, a compre-
hensive search was conducted [34]. Although Scopus covers
IEEE Xplore and Elsevier, the two databases were included to
verify the quality of the search strings. Based on the selected
database, the search string was adapted to the specific needs
of each search engine.
c) Study Selection: The study selection was processed
in four iterations. We excluded studies and publications which
are not relevant for our mapping study. To make this decision
more objective, we defined the inclusion and exclusion criteria
as summarized in Table II.
In the first iteration, we included articles based on title
and keywords. In the second iteration, we filtered by abstracts
before we read the full article in the third iteration. The studies
remaining after this iteration were used as starting set to for the
backward and forward snowball search in the fourth iteration.
Fig. 2. Search process and filtering steps.
C. Execution
We executed the mapping study as described in the previous
section. An overview of the process and the number of papers
is shown in Figure 2. In the first iteration, we identified 25
papers addressing the Product Owner and 7 addressing the
On-site Customer (after having excluded duplicates) based on
their titles and keywords. In the second iteration, we filtered
the papers with respect to the inclusion and exclusion criteria
based on abstract and keywords. This led to an exclusion of
3 papers addressing the PO. The review of the full text in the
third iteration resulted in a the preliminary set of 10 (PO) and
5 papers (On-site Customer). However, we used these sets as
starting set to conduct the snowballing sampling. As described
by Wohlin et al. [45], we considered the references of the
papers and the papers in which at least one of these 15 papers
is cited. We applied the same process of the iterations 1 to
3 with the set of papers found during snowballing, i.e., we
filtered the papers with respect to the inclusion and exclusion
criteria and considered the title, keywords, abstract as well as
the full text in the according iterations. Eventually, this led to
the final set of 10+7 (PO) and 5+8 (On-site Customer) papers
which should provide an insight in the current research status.
D. Data Extraction
To extract data from the identified studies, we developed the
form shown in Tab. III. Each data extraction field has a data
TABLE II
INCLUSION AND EXCLUSION CRITERIA
Inclusion
Paper discusses Product Owner in general
Paper discusses Product Owner in industry / organizations
Paper is a peer-reviewed contribution to a conference or a journal
Publication is a master- or PhD-thesis or a technical report
Exclusion
Paper has no accordance with Product Owner and On-site Customer
Duplicated papers
Paper is not accessible
Paper was written before 2001
Paper is not written in English or German
item, value and if applicable, is mapped to the corresponding
research question. The extraction was performed by the first
author and reviewed by the second author by tracing back the
information in the extraction form to the statements in each
paper and checking their correctness.
The extracted data of each item were tabulated and are
visually presented in Sec. IV.
TABLE III
DATA EXTR ACT IO N FO RM
DATA ITEM VALUE RQ
General
Title Name of the article
Author Name Set of names of authors
Year of Publica-
tion
Calendar year
Study ID Integer
Content
Research Topic What topics are addressed RQ1
Research Method What research method is applied RQ1.1
Content What is the content of the contri-
bution
RQ2
External Circum-
stances
Boolean RQ3
Organizational
Structures
Integer & flat / matrix / top-down RQ3.1
Company Size Integer & small / medium / large RQ3.2
Team Dimension Integer & small / medium / large RQ3.3
Team Location Integer & distributed / co-located RQ3.4
Agile Methodology
Methodology Scrum / XP / non or both
E. Threats to Validity
The outcome of our mapping study is biased by different
factors. We will present the threats to our internal, external,
construct and conclusion validity [45].
a) Internal validity: As the study was mainly executed
by one researcher, the decision on the inclusion or exclusion
of a paper mainly depended on one opinion and hence was
subjective. In order to reduce this bias, we formulated criteria
for inclusion and exclusion of a paper. Additionally, the form
represented in Tab.III objectified the data extraction process
and was revisited by the second researcher. This retains a
certain objectivity of the results.
b) External validity: We cannot guarantee that we have
found all papers to structure the research area completely. To
mitigate this threat, we performed the snowballing step which
led to an inclusion of 15 more papers.
c) Construct validity: The construction of our study
depends on the definition of the research questions, the re-
sulting search string as well as the selection of the databases.
Although we used PICO to generate key words, we cannot
guarantee that we have considered all related keywords and
synonyms for the search string. As the project manager role is
often closely related with product ownership we added Project
Manager(s)” as a related keyword to mitigate this threat.
Nonetheless, there may be other synonyms and a different or
extended search string probably would have led to different
results. However, the papers included in the analysis draw a
broad picture of the current state of research. The results also
depend on the selection of the databases. Some publications
are listed in more than one database while others are not. To
reduce the threat of missing publications we conducted the
search on seven databases which are often used in literature
reviews.
d) Conclusion validity: Conclusion depends on the ob-
tained data which is based on the construction and external
validity. For our purpose – structuring the research area in
regard to the Product Owner – as well as to identify gaps in
current research, the data were sufficient.
IV. RES ULTS
As visualized in Fig. 2, we considered a total of 30 papers
which have been published over the last 14 years. There has
been an increased interest in the matter of Product Owner /
On-site Customers in 2007, 2008 and 2009. However, the most
attention was gained within the past two years as can be seen
in Fig. 3.
Fig. 3. Publications by year.
In the following subsections, we present our results accord-
ing to the research questions described in Section III. We
present the extracted data based on the Table III. The results
from the mapping study are visually prepared.
A. Research Question 1
Our first research question aimed to provide an overview of
the addressed research topics regarding the PO role in industry
and the applied research methods to answer them.
We categorized the addressed questions and identified seven
topics. They are addressed in the context of Scrum, XP
or for agile methodologies in general. Also, seven applied
research methods have been identified. Unfortunately, in three
contributions we were not able to determine the research
method as it has not been described sufficiently.
Most publications are addressing the Functions / Chal-
lenges & Responsibilities (30%), compared Theory vs. Prac-
tice (25%) and reported Success Factors (16%) of Product
Owners and On-site Customers. The least attention was paid
to the topic of Requirements Engineering practices of Product
Owners / On-site Customers. An overview of the topics is
visualized in Figure 4.
Fig. 4. Research topics addressing the PO / On-Site Customer Role in
literature.
Most of the researchers collected their data with a case study
(27%), conducted semi-structured interviews (18%) or shared
their own experiences in an experience report (18%).
To get a comprehensive overview of what methods have
been used to answer the research questions of the according
topics, we mapped the results in Fig. 5.
Table IV maps the references in regard to the addressed agile
practices and research topics. It visualizes that the research
topic ’scaling PO role’ and ’requirements engineering’ are
considered in scrum only, while ’theory vs. practice’ as well
as ’collaboration / involvement’ mostly consider XP practices.
Three contributions considered agile practices as a whole and
did not specify any framework. They are summarized in the
’mix’ category.
B. Research Question 2
After having identified what research topics are addressed
in current literature, we were interested in the answers they
provide.
Fig. 5. Systematic Map of Research Question 1 and 1.1.
TABLE IV
PUBLICATIONS BY RESEARCH TOPIC AND METHODOLOGY
SCRUM XP Mix
Scaling PO
Role
[2, 11, 32, 7, 25,
17]
Functions /
Challenges &
Responsibilities
[3, 2, 21, 35, 40,
41, 7, 25, 10, 17,
36]
[27, 30, 43, 9, 29,
28, 42, 31, 44]
[16, 13]
Leadership /
Management
[40] [39, 16]
Success Factors [2, 32, 35, 7, 25,
36]
[46, 29, 31, 44] [13, 16]
Theory
vs.
Practice
[12, 40, 41, 10,
17, 36]
[20, 27, 30, 43, 9,
26, 42, 31, 44]
[39]
Requirements
Engineering
[12]
Collaboration /
Involvement
[29, 28, 44, 20,
30, 43, 15, 46]
[13, 16]
1) Scaling PO role: When scaling the role of the PO to
large projects some publications (e.g., [2, 32, 7, 3]) report
the concept of PO teams as helpful. However, the roles
and hierarchical structures within the PO teams differ. While
Bass et al. [2, 3] basically distinguish between technical and
governance PO roles, Paasivaara et al. [32] report hierarchical
structures containing one Main / Chief Product Owner (CPO)
and multiple Area Product Owners (APO) or Proxy Prod-
uct Owners (PPO). They distinguish customer-focused and
technically-focused PO roles. And yet Croix and Easton [7]
defined their product owner teams consisting of more diverse
roles (such as customers, designers, analysts, security experts,
operations experts).
Rather than forming formal PO teams, others highlight the
importance of a working communication structure within vari-
ous roles to support the Product Owner: Gupta et al. [11] report
good experiences in using ”Obeya Wall” to communicate and
define focus areas of Project Managers / Scrum Masters and
Product Managers / Product Owners while Lowery and Evans
[25] propose one PO for the bigger picture who is supported
by multiple in-team Subject Matter Experts (SME’s).
When it comes to smaller companies, Bass et al. [17]
identified the concept of a PO team as not feasible.
Takeaway: In large scale projects the PO role is a group
effort.
2) Functions, Challenges & Responsibilities: When de-
scribing the tasks of POs, some authors categorized them as
a function or responsibility while others emphasized them
as a challenge for the PO. To improve readability, here we
summarize them simply as activities. In total 21 different
activities of POs were mentioned in the considered literature.
The most frequently named activity of Product Owners is
Communication An overview of the activities and the refer-
ences is presented in TabV.
Takeaway: PO role is a communicator role.
3) Leadership / Management: The aspect of leadership and
management in regard to the PO was only considered in three
publications. Shastri et al.[39] discovered that – in practice –
the project manager is still in place in large projects, although
this role should be replaced by the Scrum Master or Product
Owner. Beside the formal role descriptions Sverrisdottir et al.
TABLE V
ACTIVITIES OF PO
Activities Reference
Communication [35, 41, 30, 16, 10, 2, 3, 17, 40, 21].
Writing user stories [2, 3, 44]
Planning [40, 9]
Prioritize the backlog [2, 3, 17]
Mastering the releases [2, 3, 17]
Technical architect [2, 3]
Governor [2, 3]
Traveller [2, 3, 17]
Intermediary [2, 3, 17]
Risk assessor [2, 3]
Gate keeper [17]
Acceptance tester [27, 44, 3, 17, 36]
Customer relationship manager [3, 17, 10, 21]
Managing expectations [40, 9]
Political advisor [27]
Super secretary [27]
Visionary [16, 21]
Accountability [16]
Teamwork [10]
Expert trainer [44]
Critical decision maker [28]
[40] as well as Judy and Krummins-Beens [16] report that
the understanding of the role and responsibility of the PO is
quite different between organizations but seldom in perfect
conformance with the official Scrum method.
Takeaway: The PO management role is not clearly defined.
4) Success Factors: The most frequently named success
factors for Product Owners are the relationship between the
PO and the development team as well as the stakeholders.
Although Koskela and Abrahamsson [20] identified that only
21% of the on-site customers time was required for assisting
the development team in the actual development work, having
local PO representatives [32, 46, 10] or a Subject Matter
Expert [25, 44] on-site is considered as the main differentiator
when it comes to communicate responsibilities [32, 7] and pri-
orities [32] clearly. Working closely with the team establishes
a partnership of trust and teamwork, which is considered as a
success factor [16, 25, 44, 36].
Takeaway: Relationship management is key.
5) Theory vs. Practice: When researchers explicitly com-
pared a PO role to the description of another publication or
analyzed real-world scenarios against theoretical definitions
regarding the PO role, we categorize this as ’theory vs.
practice’. With regard to the topic of functions, challenges &
responsibilities, for example Bass et al. [17] compared their
own findings of the PO role in large enterprise settings [2] to
the PO role in small companies. Unger-Windeler and Kl¨
under
[41] compared the tasks described by Bass et al. [2] to the tasks
of POs in a system development environment. Sverrisdottir et
al. [40] compared general descriptions of the PO role to actual
role description in industry. In regard to the topic of leadership
and management in agile software development, Shastri et
al. [39] analyzed to what extent the Project Manager role is
still encountered in the agile industry although it is officially
replaced by the Scrum Master or PO role.
However, regardless of the topic the result of every com-
parison was always the same: it did not match. A possible
explanation for this is that the settings of the two objects
of comparison were not equal. Which in turn would be an
indication for the importance of the environment to properly
describe the PO role in industry.
Takeaway: No PO role is like the other.
6) Requirements Engineering: We only found one publi-
cation that discussed the PO role related to Requirements
Engineering. Heikkila et al. [12] describe the requirements
flow from strategy to release in a large-scale agile development
and described the definition of the PO role as insufficient and
thus as problematic for the process. However, this publication
does not provide insights in the requirements engineering
practices of POs.
Takeaway: Real insights in PO requirements engineering
practices are absent.
7) Collaboration / Involvement: The results regarding the
collaboration / involvement of POs or On-site Customers are
closely related to the success factors. Hoda et al. [13] stud-
ied the impact of insufficient customer involvement on self-
organizing agile teams. They identified problems in gathering
and clarifying requirements, problems in prioritizing require-
ments, problems in securing feedback, loss of productivity,
and in extreme cases, business loss. Supporting this, Woj-
ciechowski et al. [46] report that On-site Customer practice has
substantial positive influence on quality of communication and
speed of software production. Hence, adequate involvement
and collaboration is necessary. However, although it is stated
that most of the POs time on-site is idle [20, 30] its absence
is identified as cause for lack of involvement [13]. Hence, the
collaboration needs to be designed more efficiently [43]
A solution for this is provided by Williams et al. [44]. They
report extreme success as they have representatives on-site for
a while in order to establish a close relationship between the
customer and the development team so that the collaboration
continues even though the customer is absent again. In turn,
these reports go along with the success factor of relationship
management.
Takeaway: The better the relationship, the better the
collaboration.
A consolidated list is presented in Tab. VI.
C. Research Question 3
The last research question aims to provide an overview
of the consideration rate of the POs environment in terms
of team dimension and location as well as company size
and its organizational structures. Surprisingly, the external
circumstances for a PO are barely considered.
1) Teams: Overall, 60% of the publications (18 out of 30)
mention the dimensions of the team the Product Owner / On-
site Customer is working with. Out of this, 16 publications
TABLE VI
RESEARCH TOP ICS A ND TAK EAWAY MES SAG ES
Topic Takeaway message
Scaling PO role In large scale projects the PO role is a group
effort.
Functions, Challenges &
Responsibilities
PO role is a communicator role.
Leadership / Management Product Owner management role is not
clearly defined.
Success Factors Relationship management is key.
Theory vs. Practice No PO role is like the other.
Requirements
Engineering
Real insights in PO requirements engineer-
ing practices are absent.
Collaboration / Involve-
ment
The better the relationship the better is the
collaboration.
mention large teams. While 7 of them consider globally
distributed teams, only 3 report of co-located teams. The
remaining 6 publications do not mention the location of the
teams at all. An overviews is presented in Figure 6.
Fig. 6. Publications consider team dimensions.
2) Company: The recognition of the POs external circum-
stances in terms of the company and its organization is sparse
in current literature as only 33% (10 out of 30) consider
these factors at all. While as much as 27% mention the size
of the company (7 large, 1 small), only 17% mention the
organizational structure (2 top-down, 2 flat, 1 matrix) of the
POs environment. See Fig.7.
We mapped the references in regard to the addressed
organizational structure and the company size (see Tab. VII).
V. DISCUSSION
Product Owners as well as On-site Customers have an
important role in the agile software development process.
However, there seem to be several scattered results on this
role. What is missing is a conclusive bigger picture of the
studies and reports on this issue. To fill this gap, we conducted
a systematic mapping study.
To answer the general question that drives this mapping
study, we can say that we know the following:
Fig. 7. Publications consider environment.
TABLE VII
PUBLICATIONS CONSIDER EXTERNAL CIRCUMSTANCES
Organization
Size
Top-
Down
Flat Matrix N/A
small [17]
medium
large [41] [11] [2, 3, 12, 21, 32]
N/A [9] [16] [35, 39, 40, 20,
27, 30, 43, 46,
7, 12, 13, 25, 15,
26, 29, 28, 42,
31, 44, 10, 36]
Most of the research was published in 2017 and 2018 and
it was basically focused on the Functions / Challenges &
Responsibilities (30%), the gap between Theory vs. Practice
(25%) and POs Success Factors (16%).
Content wise, we can say that On-site Customers time is
not used to 100%. In order to work as successful and efficient
as possible - the Product Owner /On-site Customer should be
a people person who gains trust and builds relationships to
all stakeholders and developers. Although the distance factor
is identified among the reasons for a lack of involvement, it
is more important for the PO to be responsive and available
to the team and communicate requirements clearly than just
being on-site. On top of that, in large-scale environments
the PO role is a group effort and PO teams seems to be
a successful method to scale this role. This study identified
a total of 21 different activities performed by POs in the
considered literature. Hence, a generic description of this role
would hardly fit all. Which of those activities are performed
by what kind of PO, by how many PO roles and at what
time depends on the external circumstances of the PO role.
However, the results of this mapping study show that the POs
external circumstances have gained very little attention in the
considered literature.
Also, what is missing are profound insights in regard of the
requirement engineering practices as well as the leadership /
management practices and responsibilities of POs – especially
with respect to other traditional management roles like the
Project / Product Manager.
Overall, what we know of Product Owners in industry
can be summarized as follows:
•21 different PO activities are identified in the considered
literature
•In large scale projects the PO role is a group effort
•PO role is a communicator role
•Product Owner management role is not clearly defined
•Relationship management is key
•No PO role is like the other
•The better the relationship the better the collaboration.
While some of the research topics are addressed in only
a few publications the consolidated results might not be
representative. Also, the consolidation of results and the drawn
conclusions were mainly done by one researcher (internal and
construction validity).
Nevertheless, we want to highlight two findings: First, the
finding: The better the relationship the better the collabo-
ration. The related publications identify reasons as well as
impacts of inadequate customer involvement and link strong
relationships to efficient and successful collaboration. How-
ever, these results only aim for the collaboration between On-
site Customer and development team. In future research, we
would be interested in the collaboration between PO roles
and traditional management roles (such as the Product or
Project Manager). This would go in conformaty with the
results regarding the Leadership / Management. They show:
the collaboration as well as the responsibilities between the PO
role and other management roles like the Project or Product
Owner are not clearly defined. Same applies to the area
of Requirements Engineering. Here, the PO’s requirements
engineering practices and collaboration with others are not
particularly addressed.
Second, the finding: No PO role is like the other.. This
conclusion emerged when analyzing the results of theory vs.
practice. There, regardless of the topic the result of every
comparison was always the same: it did not match. A possible
explanation for is that the external circumstances of the two
objects of comparison (PO roles) were not equal. Which
in turn would be an indication for the importance of the
external circumstances and would lead to the conclusion that
the consideration of them is neccesary in order to describe the
PO role in industry properly.
Additionally, we identified three gaps in current research:
1) the requirements engineering practices of POs are almost
neglected, 2) the external circumstances of POs – such as the
company size and its organizational structure – are barely
considered in current research and 3) the leadership and
management responsibilities of POs with respect to traditional
management roles are not clearly defined. The first two gaps
are suprising as both the requirements as well as the external
circumstances are stated as influential factors and important
responsibilities of this role [4, 38, 37, 6]. Hence, we expected
them to be considered more often. A possible explanation for
the low consideration rate of the enviroment is, that the authors
were not aware of the fact, that it could have an impact on
their research question - or it actually had not had an impact.
According to this, What we do not know includes the
following (but is not limited to it):
•Requirements Engineering practices of Product Owners
in industry
•Collaboration practices between Product Owners and
traditional management roles
•The real impact of the POs external circumstances
VI. CONCLUSION
In this research we conducted a systematic mapping study
to gain an overview of the aspects of the role of POs and
On-site Customers that have been addressed in research.
We identified existing literature, extracted data in respect to
addressed research topics, mapped them to the respective agile
method as well as identified applied research methods.
The contribution of this paper is the identification of the
seven research topics: (1) scaling the PO role, (2) functions,
challenges & responsibilities, (3) leadership / management,
(4) success factors, (5) theory vs. practice, (6) requirements
engineering, (7) collaboration / involvement along with the
consolidated answers for each of them.
While some of those topics provide congruent results,
others point to gaps in current research. So is the PO role
in large-scale projects clearly defined as a group effort and
communication skills are the most important skills of Product
Owners and On-site Customers. However, questions regarding
the leadership and management responsibilities of POs remain
unanswered as well as the impact of the external circumstances
on this important, yet complex role.
As a result of our findings, we hypothesize that the
description of the Product Owners environment – especially
in terms of organizational structure and the collaboration with
traditional management roles – will make a difference in the
description of this role.
ACK NOWLEDGE ME NT
This work was supported by Baker Hughes, a GE Company.
REFERENCES
[1] Scott W Ambler and Mark Lines. Disciplined agile de-
livery: A practitioner’s guide to agile software delivery
in the enterprise. IBM Press, 2012.
[2] Julian M. Bass. “How product owner teams scale agile
methods to large distributed enterprises”. In: Empiri-
cal Software Engineering 20.6 (2015), pp. 1525–1557.
IS SN: 1382-3256. DO I: 10.1007/s10664-014-9322-z.
[3] Julian M. Bass et al. “An empirical study of the
product owner role in scrum”. In: Proceedings of the
40th International Conference on Software Engineering
Companion Proceeedings - ICSE ’18. Ed. by Ivica
Crnkovic et al. New York, New York, USA: ACM Press,
2018, pp. 123–124. IS BN: 9781450356633. DOI: 10 .
1145/3183440.3195066.
[4] Kent Beck. extreme programming eXplained: Embrace
change. Reading MA: Addison-Wesley, 2000. ISBN:
0201616416.
[5] Andrew Begel and Nachiappan Nagappan. “Usage and
Perceptions of Agile Software Development in an In-
dustrial Context: An Exploratory Study”. In: First Inter-
national Symposium on Empirical Software Engineering
and Measurement (ESEM 2007). IEEE, 9/20/2007 -
9/21/2007, pp. 255–264. IS BN: 978-0-7695-2886-1.
[6] B. Boehm and R. Turner. “Management Challenges to
Implementing Agile Processes in Traditional Develop-
ment Organizations”. In: IEEE Software 22.5 (2005),
pp. 30–39. IS SN: 0740-7459.
[7] Alan de Ste Croix and Alan Easton. “The Prod-
uct Owner Team”. In: Agile 2008 Conference. IEEE,
8/4/2008 - 8/8/2008, pp. 274–279. ISBN: 978-0-7695-
3321-6. DO I: 10.1109/Agile.2008.94.
[8] Tore Dyb˚
a and Torgeir Dingsøyr. “Empirical studies of
agile software development: A systematic review”. In:
Information and Software Technology 50.9-10 (2008),
pp. 833–859. IS SN: 09505849. DOI: 10 . 1016/j. infsof .
2008.01.006.
[9] Malte Finsterwalder. “Does XP need a professional
Customer?” In: XP2001 Workshop on customer involve-
ment. 2001.
[10] Gerardo Matturro. “The role of Product Owner from
the practitioner’s perspective. An exploratory study”. In:
(2018).
[11] Rajeev Kumar Gupta, Shivani Jain, and Bharat Singh.
“Challenges in scaling up a globally distributed legacy
product”. In: Proceedings of the 13th Conference on
Global Software Engineering - ICGSE ’18. Ed. by
Maria Paasivaara, Darja ˇ
Smite, and Roberto Evaristo.
New York, New York, USA: ACM Press, 2018, pp. 77–
81. IS BN: 9781450357173. DO I: 10 . 1145 / 3196369 .
3196389.
[12] Ville T. Heikkil¨
a et al. “Managing the requirements flow
from strategy to release in large-scale agile develop-
ment: a case study at Ericsson”. In: Empirical Software
Engineering 22.6 (2017), pp. 2892–2936. IS SN: 1573-
7616. DO I: 10.1007/s10664-016-9491-z.
[13] Rashina Hoda, James Noble, and Stuart Marshall. “The
impact of inadequate customer collaboration on self-
organizing Agile teams”. In: Information and Software
Technology 53.5 (2011), pp. 521–534. IS SN: 09505849.
DO I: 10.1016/j.infsof.2010.10.009.
[14] Philipp Hohl et al. “Forces that Prevent Agile Adop-
tion in the Automotive Domain”. In: Product-Focused
Software Process Improvement. Vol. 10027. Lecture
Notes in Computer Science. Cham: Springer Interna-
tional Publishing, 2016, pp. 468–476. IS BN: 978-3-319-
49093-9.
[15] David Hussman. “Coaching a Customer Team”. In:
Extreme Programming and Agile Processes in Software
Engineering. Ed. by Gerhard Goos et al. Vol. 2675.
Lecture Notes in Computer Science. Berlin, Heidelberg:
Springer Berlin Heidelberg, 2003, pp. 254–260. IS BN:
978-3-540-40215-2. DO I: 10 . 1007 / 3 - 540 - 44870 -
5{\textunderscore}31.
[16] Ken H. Judy and Ilio Krumins-Beens. “Great Scrums
Need Great Product Owners: Unbounded Collabora-
tion and Collective Product Ownership”. In: Proceed-
ings of the 41st Annual Hawaii International Confer-
ence on System Sciences (HICSS 2008). IEEE, 1/7/2008
- 1/10/2008, p. 462. DO I: 10.1109/HICSS.2008.186.
[17] Julian MBass, Sarah Beecham, John Noll, Mohammad
Abdur Razzak. “All Hands to the Pumps: The Product
Owner Role in Small Companies”. In: ().
[18] B. Kitchenham. Guidelines for Systematic Literature
Reviews in SE. 2007.
[19] Jil Kl¨
under, Philipp Hohl, and Kurt Schneider. “Becom-
ing Agile while preserving software product lines”. In:
Proceedings of the 2018 International Conference on
Software and System Process - ICSSP ’18. Ed. by Marco
Kuhrmann, Rory V. O’Connor, and Dan Houston. New
York, New York, USA: ACM Press, 2018, pp. 1–
10. IS BN: 9781450364591. DOI: 10 . 1145 / 3202710 .
3203146.
[20] Juha Koskela and Pekka Abrahamsson. “On-Site Cus-
tomer in an XP Project: Empirical Results from a
Case Study”. In: Software Process Improvement. Ed. by
David Hutchison et al. Vol. 3281. Lecture Notes in
Computer Science. Berlin, Heidelberg: Springer Berlin
Heidelberg, 2004, pp. 1–11. IS BN: 978-3-540-23725-9.
DO I: 10.1007/978-3-540-30181-3{\textunderscore}1.
[21] Sigurhanna Kristinsdottir, Marta Larusdottir, and ˚
Asa
Cajander. “Responsibilities and Challenges of Product
Owners at Spotify - An Exploratory Case Study”. In:
Human-Centered and Error-Resilient Systems Develop-
ment. Ed. by Cristian Bogdan et al. Cham: Springer
International Publishing, 2016, pp. 3–16. ISBN: 978-3-
319-44902-9.
[22] Maarit Laanti, Outi Salo, and Pekka Abrahamsson.
“Agile methods rapidly replacing traditional methods at
Nokia: A survey of opinions on agile transformation”.
In: Information and Software Technology 53.3 (2011),
pp. 276–290. IS SN: 09505849. DOI: 10 . 1016/j. infsof .
2010.11.010.
[23] Craig Larman. Scaling lean & agile development: think-
ing and organizational tools for large-scale Scrum.
Pearson Education India, 2008.
[24] Dean Leffingwell. Scaling software agility: best prac-
tices for large enterprises. Pearson Education, 2007.
[25] Mike Lowery and Marcus Evans. “Scaling Product
Ownership”. In: AGILE 2007 (AGILE 2007). IEEE,
8/13/2007 - 8/17/2007, pp. 328–333. ISBN: 0-7695-
2872-4. DO I: 10.1109/AGILE.2007.51.
[26] A. Martin, R. Biddle, and J. Noble. “The XP Customer
Role in Practice: Three Studies”. In: Agile Development
Conference. IEEE, 22-26 June 2004, pp. 42–54. ISBN:
0-7695-2248-3. DOI: 10.1109/ADEVC.2004.23.
[27] Angela Martin, Robert Biddle, and James Noble. “The
XP Customer Team: A Grounded Theory”. In: 2009
Agile Conference. IEEE, 8/24/2009 - 8/28/2009, pp. 57–
64. IS BN: 978-0-7695-3768-9. DOI: 10.1109 / AGILE .
2009.70.
[28] Angela Martin, James Noble, and Robert Biddle. “Being
Jane Malkovich: A Look Into the World of an XP
Customer”. In: Extreme Programming and Agile Pro-
cesses in Software Engineering. Ed. by Gerhard Goos
et al. Vol. 2675. Lecture Notes in Computer Science.
Berlin, Heidelberg: Springer Berlin Heidelberg, 2003,
pp. 234–243. ISBN: 978-3-540-40215-2. DOI: 10.1007/
3-540-44870-5{\textunderscore}29.
[29] Angela Michelle Martin. “The role of customers in
extreme programming projects”. In: (2009).
[30] Shahriar Mohammadi, Bahman Nikkhahan, and Sahar
Sohrabi. “An Analytical Survey of On-Site Customer
Practice in Extreme Programming”. In: International
Symposium on Computer Science and its Applications.
IEEE, 10/13/2008 - 10/15/2008, pp. 1–6. ISBN: 978-0-
7695-3428-2. DO I: 10.1109/CSA.2008.72.
[31] Cesar Farell Rekha Narang and Shelley Kapitan Heather
Webber. “Towards an Effective Onsite Customer Prac-
tice”. In: ().
[32] Maria Paasivaara, Ville T. Heikkila, and Casper Lasse-
nius. “Experiences in Scaling the Product Owner Role
in Large-Scale Globally Distributed Scrum”. In: 2012
IEEE Seventh International Conference on Global
Software Engineering. IEEE, 8/27/2012 - 8/30/2012,
pp. 174–178. ISBN: 978-1-4673-2357-4. DOI: 10.1109/
ICGSE.2012.41.
[33] Kai Petersen, Sairam Vakkalanka, and Ludwik Kuz-
niarz. “Guidelines for conducting systematic mapping
studies in software engineering: An update”. In: Infor-
mation and Software Technology 64 (2015), pp. 1–18.
IS SN: 09505849. DOI: 10.1016/j.infsof.2015.03.007.
[34] Kai Petersen et al. “Systematic Mapping Studies in Soft-
ware Engineering.” In: EASE. Vol. 8. 2008, pp. 68–77.
[35] Dharmesh Raithatha. “Making the whole product agile–
a product owners perspective”. In: International Confer-
ence on Extreme Programming and Agile Processes in
Software Engineering. Springer. 2007, pp. 184–187.
[36] Sandra Oomen. “HOW CAN SCRUM BE SUCCES-
FUL COMPETENCES OF THE SCRUM PRODUCT
OWNE.pdf”. In: (). (Visited on 2017).
[37] Ken Schwaber, ed. The Scrum Guide: — the definitive
guide to Scrum: The rules of the game. 2017. URL:
scrum.org.
[38] Ken Schwaber and Mike Beedle. Agile software de-
velopment with Scrum. Series in agile software devel-
opment. Upper Saddle River, NJ: Prentice Hall, 2002.
IS BN: 9780130676344.
[39] Y. Shastri, R. Hoda, and R. Amor. “Does the ’project
manager’ still exist in agile software development
projects?” In: Proceedings - Asia-Pacific Software En-
gineering Conference, APSEC (2017). DOI: 10. 1109/
APSEC.2016.019.
[40] Hrafnhildur Sif Sverrisdottir, Helgi Thor Ingason, and
Haukur Ingi Jonasson. “The Role of the Product Owner
in Scrum-comparison between Theory and Practices”.
In: Procedia - Social and Behavioral Sciences 119
(2014), pp. 257–267. ISSN: 18770428. DOI: 10.1016/j.
sbspro.2014.03.030.
[41] Carolin Unger-Windeler and Jil Kluender. On the Tasks
and Characteristics of Product Owners: A Case Study
in the Oil & Gas Industry.
[42] Nathan Wallace, Peter Bailey, and Neil Ashworth.
“Managing xp with multiple or remote customers”.
In: Third International Conference on eXtreme Pro-
gramming and Agile Processes in Software Engineering
(XP2002). 2002.
[43] Xiaohua Wang, Zhi Wu, and Ming Zhao. “The Rela-
tionship between Developers and Customers in Agile
Methodology”. In: 2008 International Conference on
Computer Science and Information Technology. IEEE,
8/29/2008 - 9/2/2008, pp. 566–572. ISBN: 978-0-7695-
3308-7. DO I: 10.1109/ICCSIT.2008.9.
[44] Michelle Williams et al. “How We Made Onsite Cus-
tomer Work - An Extreme Success Story”. In: AGILE
2007 (AGILE 2007). IEEE, 8/13/2007 - 8/17/2007,
pp. 334–338. ISBN: 0-7695-2872-4. DOI: 10 . 1109 /
AGILE.2007.33.
[45] Claes Wohlin, Martin H¨
ost, and Kennet Henningsson.
“Empirical Research Methods in Software Engineer-
ing”. In: Empirical Methods and Studies in Software
Engineering. Ed. by Gerhard Goos et al. Vol. 2765.
Lecture notes in computer science. Berlin, Heidelberg:
Springer Berlin Heidelberg, 2003, pp. 7–23. IS BN: 978-
3-540-40672-3. DOI: 10 . 1007 / 978 - 3 - 540 - 45143 -
3{\textunderscore}2.
[46] Adam Wojciechowski, Maciej Wesolowski, and Woj-
ciech Complak. “Experimental Evaluation of ’On-Site
Customer’ XP Practice on Quality of Software and
Team Effectiveness”. In: On the Move to Meaning-
ful Internet Systems: OTM 2010 Workshops. Ed. by
Robert Meersman, Tharam Dillon, and Pilar Herrero.
Vol. 6428. Lecture Notes in Computer Science. Berlin,
Heidelberg: Springer Berlin Heidelberg, 2010, pp. 269–
278. IS BN: 978-3-642-16960-1. DOI: 10 .1007 /978 - 3 -
642-16961-8{\textunderscore}45.
