Conference PaperPDF Available

A Mapping Study on Product Owners in Industry: Identifying Future Research Directions


Abstract and Figures

Product Owners in the Scrum framework-respectively the On-site Customer when applying eXtreme Programming 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, others 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.
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
Jil Kl¨
Leibniz Universit¨
at Hannover
Software Engineering Group
Kurt Schneider
Leibniz Universit¨
at Hannover
Software Engineering Group
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
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.
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
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.
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
In particular, we are interested in answering the following
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
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
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
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.
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)”
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
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
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
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.
Title Name of the article
Author Name Set of names of authors
Year of Publica-
Calendar year
Study ID Integer
Research Topic What topics are addressed RQ1
Research Method What research method is applied RQ1.1
Content What is the content of the contri-
External Circum-
Boolean RQ3
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
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.
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
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
Fig. 5. Systematic Map of Research Question 1 and 1.1.
Scaling PO
[2, 11, 32, 7, 25,
Functions /
Challenges &
[3, 2, 21, 35, 40,
41, 7, 25, 10, 17,
[27, 30, 43, 9, 29,
28, 42, 31, 44]
[16, 13]
Leadership /
[40] [39, 16]
Success Factors [2, 32, 35, 7, 25,
[46, 29, 31, 44] [13, 16]
[12, 40, 41, 10,
17, 36]
[20, 27, 30, 43, 9,
26, 42, 31, 44]
Collaboration /
[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
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.
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¨
[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
Takeaway: The better the relationship, the better the
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
Topic Takeaway message
Scaling PO role In large scale projects the PO role is a group
Functions, Challenges &
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.
Real insights in PO requirements engineer-
ing practices are absent.
Collaboration / Involve-
The better the relationship the better is the
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).
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.
Flat Matrix N/A
small [17]
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
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
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.
This work was supported by Baker Hughes, a GE Company.
[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 .
[4] Kent Beck. extreme programming eXplained: Embrace
change. Reading MA: Addison-Wesley, 2000. ISBN:
[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 .
[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:
[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 .
[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-
[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 -
[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 .
[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 ˚
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-
[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 .
[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 .
[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/
[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/
[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-
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:
[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/
[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.
[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 /
[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 -
[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 -
... 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. ...
... 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. ...
... 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. ...
Full-text available
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.
... To minimize the risk of missing papers that are only available in a limited number of databases, we included a total of five databases in our search. Our selection follows the selections of other SMSs or SLRs in the SE domain [45][46][47][48][49][50][51][52] and consists of: Science Direct, 7 IEEE Xplore, 8 ACM Digital Library, 9 Springer Link, 10 and Google Scholar. 11 We conducted a comprehensive search as proposed by Petersen et al. [44] in each of these databases in order to reduce biases. ...
... Some publications are listed in multiple databases, while others are only listed once. For our SMS, we searched five scientific databases that have been used by several other SMSs or SLRs in the SE domain [45][46][47][48][49][50][51][52]. ...
Context Software development is a collaborative task. Previous research has shown social aspects within development teams to be highly relevant for the success of software projects. A team’s mood has been proven to be particularly important. It is paramount for project managers to be aware of negative moods within their teams, as such awareness enables them to intervene. Sentiment analysis tools offer a way to determine the mood of a team based on textual communication. Objective We aim to help developers or stakeholders in their choice of sentiment analysis tools for their specific purpose. Therefore, we conducted a systematic mapping study (SMS). Methods We present the results of our SMS of sentiment analysis tools developed for or applied in the context of software engineering (SE). Our results summarize insights from 106 papers with respect to (1) the application domain, (2) the purpose, (3) the used data sets, (4) the approaches for developing sentiment analysis tools, (5) the usage of already existing tools, and (6) the difficulties researchers face. We analyzed in more detail which tools and approaches perform how in terms of their performance. Results According to our results, sentiment analysis is frequently applied to open-source software projects, and most approaches are neural networks or support-vector machines. The best performing approach in our analysis is neural networks and the best tool is BERT. Despite the frequent use of sentiment analysis in SE, there are open issues, e.g. regarding the identification of irony or sarcasm, pointing to future research directions. Conclusion We conducted an SMS to gain an overview of the current state of sentiment analysis in order to help developers or stakeholders in this matter. Our results include interesting findings e.g. on the used tools and their difficulties. We present several suggestions on how to solve these identified problems.
... In our mapping study, 14 we found communication to be the most frequently mentioned task of Product Owners in literature. Several researcher identified communication to be of particular importance in the development process (cf. ...
... RQ The key statement that resulted from the above answered research questions is that Product Owners are communicators. 14 ...
Full-text available
Product Owners have an important role in the agile and hybrid software development process. While this role is supposed to maximize the value of a product, there seem to be several scattered results on how they achieve this, as well as what actually constitutes this role in practice. To consolidate current research results and to further analyze the key attribute of Product Owners, we conducted a multi‐method research approach spanning a systematic mapping study and a consecutive case study in a hybrid development environment. The results of the mapping study states that Product Owners are communicators. We further investigated on this and used the shadowing technique to observe three Product Owners' communication activities. The results support that statement, as the gained data reveal that Product Owners spend 65% of their time in meetings. But rather than just providing the team with the necessary requirements for the product under development, Product Owners need this time to synchronize and align their work, streamline the agile process of large‐scale Scrum, discuss team‐based topics, and to solve upcoming issues addressed by the team. These results contribute to draw a more comprehensive picture of the important but yet complex role of Product Owners in practice.
... These are only a subset of the issues that can arise due to the Development and Operations teams working in isolation and chasing their own KPIs. None of the product owners [45], developers [46], or team leaders from either team are responsible for addressing the issues mentioned above. Even though these issues can be solved, this requires more discussions and code exchanges between the Development and Operations teams. ...
Full-text available
In the Software Development Life Cycle (SDLC), Development and Operations (DevOps) has been proven to deliver reliable, scalable software within a shorter time. Due to the explosion of Machine Learning (ML) applications, the term Machine Learning Operations (MLOps) has gained significant interest among ML practitioners. This paper explains the DevOps and MLOps processes relevant to the implementation of MLOps. The contribution of this paper towards the MLOps framework is threefold: First, we review the state of the art in MLOps by analyzing the related work in MLOps. Second, we present an overview of the leading DevOps principles relevant to MLOps. Third, we derive an MLOps framework from the MLOps theory and apply it to a time-series forecasting application in the hourly day-ahead electricity market. The paper concludes with how MLOps could be generalized and applied to two more use cases with minor changes.
... 22 Furthermore, this session also included one of the papers that were invited for our special issue, focusing on the role of product owners in industry. 23 ...
Full-text available
The volume at hand presents the special issue of the 12th International Conference on Software and Systems Process (ICSSP) 2019, which was held in Montreal, Canada, from May 25 to 26, 2019. ICSSP 2019 is the latest in a series of conferences that have been organized by the International Software and Systems Process Association. In our evolving landscape, many companies are making efforts to move towards new technologies and tools, agile principles, and continuous integration and delivery. In doing so, they find opportunity, flexibility, and strength in evolving towards hybrid processes, which are neither purely traditional nor can count as textbook agile. This special issue focuses on hybrid processes.
... To decrease the threat of the database selection, we oriented ourselves by other successfully conducted SLRs and chose five databases to reduce the threat of missing papers [17,43]. ...
Full-text available
Agile software development methods promise shorter time-to-market and higher product quality, but lack the ability of long-term planning or coping with large projects. However, software companies often also want the ability of long-term planning, promised by traditional or plan-based methods. To benefit from the strengths of both approaches, software companies often use a combination of agile and plan-based methods, known as hybrid development approaches. These approaches strongly depend on the individual context and are customized. Therefore, companies have to organize their hybrid development approach individually. However, practitioners often have difficulties with the organization of hybrid approaches. The organization considers how the phases, activities, roles, and artifacts are arranged and connected. Research lacks the necessary detailed insight into how hybrid development approaches are organized to support practitioners. To gain better understanding of the organization of hybrid approaches, we conducted a systematic literature review to gather descriptions of hybrid approaches. We analyzed the found papers thoroughly and could identify three general patterns of how hybrid approaches are organized. We found that all these patterns are still based on Royce's waterfall model and use the standard software engineering activities. Our findings shall help to lead further research and help practitioners to better organize their individual development approach. CCS CONCEPTS • Software and its engineering → Collaboration in software development ; Agile software development; Waterfall model. KEYWORDS Hybrid software development; agile software development; software process; systematic literature review
Full-text available
A abordagem de gerenciamento ágil de projetos inova ao estabelecer um conjunto de novas práticas de gestão, como planejamento iterativo, visão do produto e participação ativa do cliente no processo de desenvolvimento do projeto. A participação ativa do cliente é implementada por meio da figura do Product Owner. Porém, como proceder quando esse profissional não está presente ou não está comprometido? Como suas tarefas são distribuídas entre os membros da equipe? Essas tarefas são realmente feitas? Qual o impacto? Essa pesquisa analisa equipes que não contam com o papel específico de Product Owner. Para tal, empregou-se uma revisão das tarefas designadas pela literatura para esse papel e, a partir desses resultados, fez-se uma pesquisa do tipo estudo de caso em equipes que fazem uso das práticas do gerenciamento ágil sem a presença do Product Owner. O trabalho identificou que nos projetos com o Product Owner pouco atuante houve prejuízo maior que um projeto em que não havia este papel formalmente definido, sendo distribuído para outros profissionais. Os resultados apontam a proposição de que o Scrum Master poder ficar sobrecarregado quando o Product Owner não faz suas tarefas a contento. Por fim, apesar do entendimento da importância e necessidade desse papel, foi possível perceber que os projetos estudados tiveram sucesso para os clientes mesmo sem a presença Product Owner. Recomenda-se estudos futuros que possam generalizar estes resultados identificando a melhor forma de distribuir os papéis do Product Owner em situações de ausência.
Full-text available
News recommenders are attracting widespread interest in scholarly work. The current research paradigm, however, holds a narrow (mostly user-centered) perspective on the recommendation task. This makes it difficult to understand that their design is in fact the result of a negotiation process among multiple actors involved, such as editors, business executives, technologists and users. To remedy this, a multi-stakeholder recommendation paradigm has been suggested among recommender systems scholars. This work sets out to explore to what extent this paradigm is applicable to the particular context of news recommenders. We conducted 11 interviews with professionals from three leading media companies in Flanders (Belgium) and find that the development of news recommenders is indeed characterized by a negotiation process among multiple stakeholders. However, our results show that the initial multi-stakeholder framework is not adequately accommodating some of our findings, such as the existence of preconditions, the role of product owners, and the indirect involvement of particular stakeholders. Based on our analysis , we suggest an elaborated framework for multi-stakeholder news recommenders that can contribute to scholarship by providing a multi-sided perspective towards the understanding of news recommenders.
Agile methods appeared in the 90s. Seen as a performance lever in the software industry, they have become a source of inspiration for a growing number of organizations. If the literature has shown a growing interest on questions of performance, little has been studied about the subjective experience of the actors practicing them. Our research aims at filling this gap while studying the category of actors playing the role of Product Owners who are supposed to be the voice of the outside world towards the agile team. This role puts the actors on the borders of possibly contradictory environments and the success of agile adoption in organizations often depends on them. The study we carried out in the Digital Factory of an industrial company allows to identify under what conditions actors can effectively endorse this role, thanks to the analysis of their psychosocial dynamics.
Die Entwicklung von Software erfolgt im Rahmen von Projekten. Projekte benötigten eine angemessene Vorgehensweise. Wir sprechen von Vorgehensmodellen. Diese beschreiben die Aufbauorganisation sowie die Ablauforganisation eines Projektes. In der Aufbauorganisation wird die Teamstruktur festgelegt und in der Ablauforganisation der Prozess für die einzelnen Schritte zur Durchführung der Entwicklung. Darüber hinaus sind geeignete Methoden für die Durchführung der geplanten Arbeitsschritte und zur Erarbeitung der Zwischenergebnisse, den Artefakten, zu wählen. Der Zusammenhang zwischen den Artefakten wird in einem sogenannten Artefaktmodell festgelegt. Wesentliche Artefakte sind der Programmcode für das Softwaresystem, aber auch die Beschreibung der Anforderungen an das Softwaresystem, seine Architektur, seiner Qualitätseigenschaften oder der zu verwendenden Testfälle. Die Wahl des Vorgehensmodells bestimmt in weiten Teilen wesentliche Faktoren der Softwareentwicklung wie die Kosten, den Zeitaufwand und die erreichte Qualität. Vorgehensmodelle sind ein wesentliches Bindeglied zwischen Fragen der Organisation und des Managements und der technischen Durchführung von Softwareprojekten. Dieses Kapitel führt die grundlegenden Vorgehensmodelle und Rollen in Projekten ein und erläutert traditionelle und agile Vorgehensmodelle im Kontext der Softwareentwicklung.
Conference Paper
Full-text available
The role of Product Owner (PO) is an essential component of the Scrum methodology. This role is well defined in the literature in terms of its responsibilities and the skills that the person who performs it should have. However, in the field, the understanding of the role and its responsibilities is quite different among organizations, and rarely in perfect compliance with the official Scrum methodology. This article reports an exploratory study about how this role is performed in industrial practice. Through semi-structured interviews conducted with a group of POs, we investigated the procedure and criteria for choosing the person for the role, the ceremonies in which they participate, and the desirable soft skills in a good PO. Findings reveal that: a) the recommendation that the PO should be a representative of the business area that will benefit from the solution is not fulfilled, b) the ceremonies that the POs always attend are sprint planning and sprint review, and c) the most valued soft skills in a PO are communication, teamwork and customer-orientation.
Full-text available
Software process improvement has always been an essential part of software projects. Current market trends and the rapid pace of changing requirements demand fast development and adaptability. Agile software development is a popular possibility to react on these trends. Implementing agile practices promises for example a shorter time-to-market, satisfied customers and increased software quality. Consequently many companies strive for an integration of agile methods or for an agile transformation. High-technological environments such as the automotive domain also want to benefit from the advantages promised by agile software development. Even more than smaller companies, these large ones have to deal with software systems getting more and more complex. One established solution facing this problem is an effective and managed way to reuse software at least partially. Software product lines provide an efficient way to manage software reuse and to handle the high complexity. Consequently, they are widely distributed in large and high-technological environments. In most companies in the automotive domain, software product lines are already present and agile development methods should be introduced. Hence, there is a need for a transformation model preserving the benefits of software product lines. We conducted a literature review to achieve an overview and a better understanding of agile transformation models in large companies. In total, we analyzed 367 papers. None of them addresses the agile transformation in large companies with existing software product lines. In consideration of this research gap, we propose a transformation model preserving the benefits of already existing models and extending aspects which are important for existing software product lines.
Full-text available
In a large organization, informal communication and simple backlogs are not sufficient for the management of requirements and development work. Many large organizations are struggling to successfully adopt agile methods, but there is still little scientific knowledge on requirements management in large-scale agile development organizations. We present an in-depth study of an Ericsson telecommunications node development organization which employs a large scale agile method to develop telecommunications system software. We describe how the requirements flow from strategy to release, and related benefits and problems. Data was collected by 43 interviews, which were analyzed qualitatively. The requirements management was done in three different processes, each of which had a different process model, purpose and planning horizon. The release project management process was plan-driven, feature development process was continuous and implementation management process was agile. The perceived benefits included reduced development lead time, increased flexibility, increased planning efficiency, increased developer motivation and improved communication effectiveness. The recognized problems included difficulties in balancing planning effort, overcommitment, insufficient understanding of the development team autonomy, defining the product owner role, balancing team specialization, organizing system-level work and growing technical debt. The study indicates that agile development methods can be successfully employed in organizations where the higher level planning processes are not agile. Combining agile methods with a flexible feature development process can bring many benefits, but large-scale software development seems to require specialist roles and significant coordination effort.
Conference Paper
Full-text available
Context: The current transformation of automotive development towards innovation, permanent learning and adapting to changes are directing various foci on the integration of agile methods. Although, there have been efforts to apply agile methods in the automotive domain for many years, a wide-spread adoption has not yet taken place. Goal: This study aims to gain a better understanding of the forces that prevent the adoption of agile methods. Method: Survey based on 16 semi-structured interviews from the automotive domain. The results are analyzed by means of thematic coding. Results: Forces that prevent agile adoption are mainly of organizational, technical and social nature and address inertia, anxiety and context factors. Key challenges in agile adoption are related to transforming organizational structures and culture, achieving faster software release cycles without loss of quality, the importance of software reuse in combination with agile practices, appropriate quality assurance measures, and the collaboration with suppliers and other disciplines such as mechanics. Conclusion: Significant challenges are imposed by specific characteristics of the automotive domain such as high quality requirements and many interfaces to surrounding rigid and inflexible processes. Several means are identified that promise to overcome these challenges.
Conference Paper
Full-text available
The project manager has been a ubiquitous feature of traditional software development projects. However, agile software development (ASD) methods which emphasize self-organizing teams and rapid response to change have done away with the project manager’s title. New job titles such as the scrum master and product owner have been introduced instead. It is unclear as to what extent the “project manager” is still encountered in the agile software industry. An online survey was posted out to agile special interest groups on popular social media platforms to discover the frequency of the job title “project manager” in agile projects. Analysis of the 97 responses from 31 countries around the world revealed that: a) the title of project manager is still widely used (67%); b) there is a correlation between the team size and presence of project manager such that there is a higher probability the project manager will be present in teams of 5-10 members and those over 25 members; and c) there is an inverse correlation between the co-location of a team and presence of project manager. Further research is needed to better understand why the project manager continues to be present on ASD projects and how their role may have changed.
Product owners in the Scrum framework – respectively the on-site customer when applying eXtreme Programming – have an important role in the development process. They are responsible for the requirements and backlog deciding about the next steps within the development process. However, many companies face the difficulty of defining the tasks and the responsibilities of a product owner on their way towards an agile work environment. While literature addresses the tailoring of the product owner’s role in general, research does not particularly consider the specifics of this role in the context of a systems development as we find for example in the oil and gas industry. Consequently, the question arises whether there are any differences between these two areas. In order to answer this question, we investigated on the current state of characteristics and tasks of product owners at Baker Hughes, a GE company (BHGE). In this position paper, we present initial results based on an online survey with answers of ten active product owners within the technical software department of BHGE. The results indicate that current product owners at BHGE primarily act as a nexus between all ends. While technical tasks are performed scarcely, communication skills seem even more important for product owners in a system development organization. However, to obtain more reliable results additional research in this area is required.
Conference Paper
This paper presents our experiences with a 120-person matrixed software engineering product team, spread across three countries that successfully scaled their adoption of Scrum. The product is a legacy, mission-critical software system that conforms to stringent healthcare regulatory standards. We are practicing Obeya wall that brings solution to our large team communication challenges and OYA day that helps solving challenges in fostering innovation, and learning culture and collaboration. We also are describing our experience of defining focus areas of project manager and product manager. These roles are not defined in scrum guide, however, is relevant in our experience in scaled up distributed scrum environment. The authors bring our experiences as a Scrum Master, Product Owner and an architect who have been integral part of the journey and establishing these practices over several years. These practices have helped in scaling as well as stabilizing the team to an extent where each product version is meeting milestones on time and taking strong steps towards shorter release cycles of quarterly releases. This paper also summaries our lessons learned, and recommendations.
The Product Owner (PO) is critical for translating business needs into a software implementation by gathering and prioritizing requirements, and assessing whether features have met the definition of "done." There is a paucity of detail about how POs achieve this daunting task in practice with potential negative consequences for project success. In this research we employed a mixed-method approach comprising two case studies in which we interviewed and observed 55 practitioners across 9 large multi-national companies and an SME. Using a cross-case analysis we identified twelve distinct Product Owner activities. From our empirical findings we created a Product Owner role taxonomy and found eight generic activities common to all teams, projects and companies regardless of project size.
Conference Paper
In Scrum, the Product Owner (PO) role is crucial for the team to be successful in developing useful and usable software. The PO has many responsibilities and challenges, including being the link between customers, other stakeholders and their development teams. This exploratory case study conducted at the software development company Spotify focuses on POs three responsibilities: (a) Identification of customers, (b) Estimation of value of their teams’ work and c) Forming a vision for the product. Additionally, challenges perceived by the POs are studied. Data was gathered through five interviews and on site observations. Results show that the POs activities are divided between daily work, such as making sure that their teams are functional and long-term activities such as making a vision for the product. The main challenge of the POs is to inspire and encourage team members to collaborate and communicate within the team and with stakeholders.