2015 48th Hawaii International Conference on System Sciences

Do Daily Scrums Have to Take Place Each Day?

A Case Study of Customized Scrum Principles at an E-Commerce Company
Daniel Pauly
University of Cologne
pauly@wiso.uni-koeln.de

Bjoern Michalik
University of Cologne
michalik@wiso.uni-koeln.de

Abstract

depth understanding and the theoretical foundations of

agile development approaches are lacking [3, 12, 13].
For the purpose of closing this research gap, several
areas for future research have been proposed. Among
others, emphasis should be placed on empirical studies
[14] related to the adaptation of agile methods [15].
Taking these calls as motivation for our study, and in
line with the growing stream of Scrum research, we pose
the following research question: How do organizations
apply Scrum principles in product management?
We answer these questions by conducting a single,
in-depth case study. Its findings contribute to a deeper
understanding of concrete applications of Scrum
principles in practice and help develop a better
understanding of reasons for adopting or adapting the
agile principles. We thus provide in-depth insights into
daily Scrum work in product management for
practitioners and help to advance Scrums theoretical
underpinnings for researchers.

Agile development approaches, such as Scrum,

continue to gain importance in todays world. Since
previous research has predominantly treated
development approaches as a black box, we answer the
call for empirical research concerning adoption of agile
methods. The studys aim is to assess the adoption or
adaption of Scrum principles at an e-commerce
company. The findings of our in-depth single case study
reveal that not all Scrum principles are suitable in each
context. By discussing the reasons for adopting or
adapting the principles, we contribute to a deeper
understanding of agile methods and help to open the
black box of development approaches in information
systems research. The in-depth insights gained at our
case company provide practitioners a useful reference
for adapting agile methods to their specific contexts.

1. Introduction

2. Product Management Scrum Principles

Popularity of agile development approaches has

increased considerably in recent years [13]. As shown
by a growing number of research studies [4], this is
particularly the case for Scrum [5], which has been
successfully applied to different types of companies and
projects [1]. Due to this success, Scrum principles have
been adopted in other domains, including product
management [1, 6].
Although detailed textbook descriptions for Scrum
exist, findings of former studies indicate that methods
commonly in use are often not enacted as prescribed, but
are rather a combination of practices implicit in different
agile methods [7]. Often, this is done to adapt the
methods to specific project, organization, and business
settings [8]. Inevitably, this has led to the emergence,
adoption, and use of various versions and
implementations of a textbook Scrum method.
Moreover, development processes are often
considered as a direct relation between input and output
variables [911], thereby neglecting their inherent
complexity. According to Siau et al. [10, p. 88], The
[development] process is either skimmed through in
literature or mated as a black box. Consequently, in-

1530-1605/15 $31.00 2015 IEEE

DOI 10.1109/HICSS.2015.601

Dirk Basten
University of Cologne
basten@wiso.uni-koeln.de

2.1. Artifacts
2.1.1 Product vision An overarching guideline for
product development [16, p. 24]. It describes the future
product in a concise and simple manner to facilitate
understanding [16, p. 27]. Thus, on one hand, the
product vision serves as a starting point, while
representing an overarching guideline during the entire
development process on the other. It should be visible,
for instance, in a document [16, p. 24]. Furthermore, a
visioning sprint [16, p. 36] can be conducted if a more
extensive effort for envisioning the product is required.
2.1.2. Product roadmap A planning artifact that
illustrates how the product will evolve within the
subsequent versions. It is none of Scrums original
principles, but rather a special extension for product
management. It should include realistic launch dates of
each version, a list of target customers (see 2.3.5) and
their needs, as well as small selection of top features. A
product roadmap should not be seen as a static
document. Rather, it evolves as the understanding of the
product increases [16, p. 41]. All stakeholders should be
5074

involved in the creation and maintenance process to

ensure their commitment.
2.1.3. Product backlog A list of product changes
for next releases. Such changes can be functional and
non-functional requirements covering business as well
as technical issues [16, p. 47]. It can also include vague
ideas for future features [5, p. 33]. Thus, the product
backlog isin line with the Scrums preference for
frequent customer feedbacka dynamic document with
evolving requirements [5, pp. 32-33]. Furthermore, it is
a prioritized list wherein higher priority items are
described in more detail and implemented first [16, p. 41].
2.1.4. Backlog items Part of product backlog,
including the necessary requirements for product
development. Different from traditional, sequential
development approaches [17], requirements in Scrum
are evolving; thus, backlog items are added, changed, or
deleted as additional information becomes available.
This additional information can emerge, for instance,
from customer feedback [16, p. 51], grooming
workshops of the Scrum team (see 2.3.1), and feedback
from stakeholders in sprint review meetings (see 2.2.4)
[16, p. 51]. If backlog items become overly extensive or
have more than one dedicated goal, they must be broken
down to fit a single sprint (see 2.2.2) [16, p. 62].
2.1.5. Definition of done List of tasks needed to
be accomplished to retrieve a working increment at the
end of each sprint. It thus serves Scrums objective to
provide a potentially shippable product at the end of
each sprint. It includes requirements, as well as efforts
for testing and documentation, all of which ensure the
increments quality [16, p. 49].
2.1.6. Sprint backlog A list of all activities that
must be completed for reaching a sprints goal. These
activities arise from the product backlog and are
sufficiently detailed to be approached in the respective
sprint [5, p. 33]. The sprint backlog is created in the
sprint planning meeting (see 2.2.1) and is updated daily
[16, p. 101], since backlog items may not be sufficiently
detailed at the beginning of the sprint [5, p. 49]. Finally,
the sprint team is the sole authority for adding,
modifying, or removing backlog items from the sprint
backlog during the sprint [5].

2.2.2. Sprint Period of time the Scrum team works

after having conducted the sprint-planning meeting. Its
recommended duration should not exceed thirty days,
but can be adapted as experience with Scrum increases
[5, p. 47]. During a sprint, the team has full authority to
do whatever is appropriate to reach the agreed sprint
goal. Burndown charts are used to consider how the
progress of the team relates to its intended results.
2.2.3. Daily Scrum Daily 15-minute meeting of
the Scrum team, allowing the members to inspect the
progress of work and to remove impediments [5, p. 41].
It is established by the Scrum master (see 2.3.4) and
takes place each day at the same place and time, thus
avoiding unnecessary coordination. Each team member
answers the following three questions: (1) What have
you worked on since the last meeting? (2) What will you
work on until the next meeting? (3) Have any
impediments occurred?
2.2.4. Sprint review meeting A four-hour meeting
in which the development team presents the work of the
preceding sprint to its stakeholders (management,
customers, users, and product owner; see 2.3.2). Each
group evaluates the results from a different perspective
[5, p. 54]. Subsequently, stakeholders provide feedback
and specifications for the following sprints [16, p. 101].
If the participants, for instance, realize that some items
have not met the definition of done, these are returned
to the product backlog and reprioritized [16, p. 102].
2.2.5. Sprint retrospective meeting A meeting
intended to allow the participants to evaluate
effectiveness and efficiency of the team collaboration
during the last sprint [16, p. 103]. Problems, their
causes, and appropriate solutions to be implemented in
the next sprint are identified. Thus, the meeting
contributes to better collaboration and enhanced job
satisfaction in the following sprints [16, p. 103].
2.2.6. Release Incremental transition of potentially
shippable product from the team into use by customers.
In Scrum, early releases are key to success. Releases
allow the team to collect early customer feedback and
enable the product to evolve [16, pp. 79-80]. Compared
to prototypes, releases are potentially shippable product
increments that nevertheless require high quality
standards [16, pp. 80-81]. Quality and time are the fixed
variables in Scrum. Nonetheless, early products may
provide fewer features than intended in the final version.

2.2. Events
Events' primary purpose is to enable transparency
and work inspection [18, p. 29].
2.2.1. Sprint-planning meeting Meeting in which
the Scrum team plans the work for the following sprint
[16, p. 98]. The resulting sprint goal is a commitment of
the team for the subsequent sprint, which fosters its selforganization, and should be realistic with regard to the
teams capacities and capabilities to hold up motivation.
The major document originating from this meeting is the
sprint backlog [5, p. 47].

2.3. Roles
The Scrum team consists of a product owner, a
Scrum master, and a development team. We also
describe customers, since their feedback is instrumental.
2.3.1. Scrum team Self-organizing and crossfunctional teams. Their objective is to bring the product
to life [16, p. 7]. Usually, they consist of five to nine
people, as smaller teams lack interaction and synergy

5075

early as possible in the development process. Thus, the

team receives early feedback and a detailed
understanding of what customers need and can therefore
develop the product in a way that provides the highest
customer benefit.
The Scrum principles serve as framework for
exploring the Scrum application in our case company.

effects, while larger teams make Scrum mechanisms

inappropriate [5, pp. 36-37]. Additionally, the team
composition should be stable to avoid losing
productivity and self-organization capabilities [16, p. 8].
It should also possess all professional skills necessary to
reach the sprint goals [5, p. 37]. Team members do not
have a job description; rather, they should be able to
participate in each task [5, p. 38]. Furthermore, the
Scrum team is authorized to make any decision
necessary to meet the sprint goals. This also includes
decisions pertaining feature implementation [5, pp. 3536]. The team members must trust each other and work
in close collaboration [16, pp. 7-8]. For this reason, all
Scrum team members should be collocated in a common
team room, facilitating communication, and interaction
and making work more enjoyable.
2.3.2. Product owner Represents the perspective
of the customer in the Scrum team. The product owner is
officially accountable for the product and has to ensure
that the right product is built in the right way [16, p. 2].
The product owner is responsible for involving all
stakeholders into the development process. His or her
main tasks are creating the product vision, managing the
product backlog, planning the release, preparing the
product launch, attending to the different sprint
meetings, and collaborating with the team [5, p. 34, 16,
p. 4]. Thus, he or she must possess the necessary
knowledge and experience, as well as be a visionary, a
leader, a team player, a communicator, and a negotiator
[16, p. 4]. Additionally, it is crucial that the product
owner has the necessary management commitment and
authority for decision-making [16, pp. 5-6].
2.3.3. Chief product owner Guides the product
owners in the process of coordinating and synchronizing
the work of different teams. The chief product owner
facilitates the collaborative decision-making and has the
power to make final decisions if, for instance, no
consensus is reached among product owners [16, p. 13].
2.3.4 Scrum master Responsible for ensuring that
Scrum is applied in the way that yields the highest
return. Compared to the product owner, the Scrum
master is not responsible for the what, but rather for
the how [16, p. 13]. That means that the Scrum master
needs to establish values, practices, and rules of Scrum
within the team [5, p. 31]. The Scrum master has to
establish all relevant Scrum meetings and foster selforganization by facilitating the work of the team.
Furthermore, he or she is responsible for resolving
impediments arising from the Daily Scrum, protecting
the team from outer and inner disturbances, and ensuring
that the team stays healthy and motivated by intervening
when, for instance, pace of work is too high [16, p. 9].
2.3.5. Customers Recipients of the product being
developed. As Scrum thrives on continuous inspection
and adaptation, it is mandatory to integrate customers as

3. Research Approach
We conducted a descriptive single case study, that is
an empirical inquiry that investigates a contemporary
phenomenon in depth and within its real-life context,
especially when the boundaries between phenomenon
and context are not clearly evident [19, p. 18]. It is
therefore especially well-suited if research problems
under investigation are complex, dynamic, and cannot
be studied outside the context in which they occur [20].
Furthermore, case studies are the preferred method of
investigation when the aim is to answer how and why
questions [19, 21]. Concerning the underlying
philosophical paradigm, we position our work
ontologically and epistemologically as positivist. The
positivist approach stems from natural sciences [22, 23].
Therein, it is believed that an objective reality exists
independently from the observer and that the world can
be comprehended by identifying cause-effect relations
not bounded in context and time [23].

3.1. Research site

The case company (henceforth referred to as
TrustMeCorp) is a medium-sized e-commerce company
founded in 1999. It is one of the leading providers of
certification services for online shops in Europe. Aiming
to build consumer trust in the e-commerce industry, it
certifies online shops by a extensive number of criteria
and secures purchases with its money-back guarantee. In
2013, sales constituted 30 million Euro while, in 2014,
its workforce surpassed 200 employees for the first time
in the companys history. Since its establishment, it has
expanded its business to ten European countries and
presently covers 13-15% of the German online stores
with its seal of approval. With offices in three major
European cities, TrustMeCorp has certified more than
17,000 online shops thus far. Operating in the dynamic
e-commerce market, it is continually forced to quickly
respond to upcoming market changes. This holds
especially true for the companys Product & Technology
department, where new and existing products are
developed. In order to ensure this high responsiveness to
market changes, the company has introduced Scrum as
an agile development framework. Although parts of
Scrum have already been used in earlier projects in
2012, an extensive utilization was first introduced in
mid-2013. At that time, the product management

5076

department was severely extended by introduction of

new employees. In addition, it merged with the
information technology department.
Four product teams have been set up (henceforth
referred to as Team A, B, C, and D). Each of the four
teams consists of seven to nine members, mainly located
in the Product & Technology department. However, so
called field experts are assigned from other
departments, so that the teams are inter-divisional and,
through their personal competencies, cross-functional as
well. While the team members were less experienced in
Scrum at its introduction, the Scrum processes in the
company have gradually improved over time.

of 2014, each lasting 60 to 90 minutes. We pretested the

interview guide with an employee of the company prior
to is usage in this study and selected the interviewees
based on maximum variation sampling [28]. Thus, we
chose three interviewees holding different roles (i.e.,
product owner, Scrum master, and team member) in
each of the four Scrum teams (cf. Table 1). As two
employees were members of two teams and one product
owner resigned from the company during the data
collection period, we conducted nine interviews in total,
each of which was audio-recorded and transcribed.
Table 1. Overview over the interviewees
No.
1
2
3
4
5
6
7
8
9

3.2. Research design

We conducted a holistic single case study, as this
approach is appropriate if the case is unique [24]. Our
research focuses on such an example, as the application
of Scrum in the particular research situation of our
chosen company can only be investigated in this context.
Moreover, it focuses on the product teams (unit of
analysis) of the Product & Technology department of
one of the leading providers of trust solutions for ecommerce in Europe. Throughout our research, we had
unlimited access to all resources and relevant
information, as one of the paper co-authors worked parttime as one of the teams Scrum master. As an employee
in the company, he could contribute invaluable insights
into the functioning of his own, as well as other teams.

Team
A
A/C
B
B/C
B
C
D
D
D

Role
Abbreviation
Product owner
A1
Product team member
AC3
Product owner
B1
Scrum master
BC2
Product team member
B3
Product owner
C1
Product owner
D1
Scrum master
D2
Product team member
D3

Finally, we had unrestricted access to all the Scrum

teams documents. This enabled us to investigate all
documents (e.g., presentations and minutes) in order to
identify information pertinent to our research question.

3.4. Data analysis

As recommended [19, 21, 25], during our study, data
analysis and data collection overlapped, for instance,
due to the researcher on-site taking field notes. Raw data
(i.e., interview transcripts, field notes, and documents)
was coded using the software NVivo. Codes were
derived from data [29]. Researcher triangulation was
broadly applied, as two researchers independently coded
each data item and consolidated their results. This
ensured all results to be developed independently from
the subjective view the researcher on-site may have
generated due to his strong involvement.

3.3. Data collection

Our data sources included participant observations,
semi-structured expert interviews, and documents.
Participant observation comprised collaboration of one
of the co-authors in the case company, who had worked
as Scrum master since the introduction of Scrum in
2013. Thus, he was able to take part in most of the
formal and informal meetings, workshops, and training
sessions. He took comprehensive field notes throughout
these events, as recommended by Yin [19] as well as
Miles and Huberman [25]. Moreover, he conducted
numerous informal discussions with all project
members. Although participant observation as a data
collection tool is inherently biased, as participants
develop an emotional relation to people, processes, and
contexts [20], we took care to objectively consider and
evaluate actions and processes. As a result, we are
confident that the participant observation did not conflict
with our underlying positivist stance (e.g., [26, 27]).
Rather, it provided the unique opportunity for unlimited
access to all relevant information, decisions, and
experiences, allowing us to gain deep contextual insights
relevant to our research question. In total, we conducted
nine semi-structured interviews during March and April

4. Results
In this section, we describe how the four Scrum
teams at our case company adapted the Scrum principles
(cf. Table 2).

4.1. Artifacts
4.1.1. Product vision. In contrast to recommendations
in the extant literature (cf. section 2), none of the four
teams studied formulates a product vision in a written
form. However, a common understanding exists
concerning the products goals and strategies.
A frequently stated reason for not using a product
vision in its proposed form is team members implicit

5077

Table 2. Summary of the Scrum application

Team
Scrum principle
A
B
C
Product vision
O
O
O
Product roadmap
X
X
X
Product backlog
X
X
X
Definition of done
---Sprint Backlog
X
X
X
Sprint planning meeting
X
X
X
Daily Scrum
X
O
O
Sprint review meeting
O
X
-Sprint retrospective meeting
O
X
-X: fully applied, O: partially applied, --: not applied

development effort. If requirements are unavailable or

insufficiently clear, estimates are either unrealistic (D1,
D2) but perceived as realistic within the company (D1),
or not provided at all, with their absence hard to explain
(B1). Additionally, product roadmaps require time for
creation (C1) and defer the teams work progress (B1).
As reasons for the involvement of team members in
developing a product roadmap, the interviewees stated
that team members are experts in their area of action and
deliver a valuable input (B1, BC2, D1, D3); thus, direct
involvement motivates the team (B1, BC2, C1, D2), and
leads to common commitment (C1, D2, D3).
In contrast, the complexity of and time required for
the creation process increases with the number of people
involved (B3, D1, D2). Additionally, teams can also be
demotivated if ideas proposed by certain members are
not reflected in the final product (A1, AC3, D2).
Several reasons exist for the adaptation of the
roadmap. The product owner might consider given
topics as inappropriate due to changes in the
environment. Additionally, adaptations can be necessary
if features are more complex than expected (AC3, B1,
B3, D1), new dependencies to other teams or
departments occur (AC3), new strategic projects arise
(B1, C1, D1, D3), or other topics are reprioritized (B1,
BC2, D1, D2). Moreover, short-dated requirements,
such as marketing or exhibition efforts, may emerge,
necessitating quick implementations (AC3). Finally,
certain team-related reasons (e.g., absences due to
sickness, shared resources, or vacations) may require
roadmaps adaptation (B1, D1, D3).
Disadvantages can occur if changes to the product
roadmap are granted. First, if plans are not finalized,
uncertainty is inevitable (AC3, BC2, D2). Additionally,
if a team has already worked on topics that are adapted
or replaced, resources are wasted (AC3, B3), team
motivation decreases (D2, B3), and stress (B3) emerges.
4.1.3. Product backlog. All four teams use a
product backlog, covering topics ranging from high to
low priority, as well as bug reports. However, every
team handles the product backlog in a unique way.
Team A splits its backlog into two parts. One part is
stored in an issue-tracking tool with a Scrum extension
called Jira, while the other is kept in an Excel file. The
Jira part is visible to all stakeholders having access to
this platform. The product backlog is not prioritized.
Team B stores the entire product backlog in Jira. It is
visible to all stakeholders having access to Jira and is
prioritized. Team C stores the entire product backlog in
Jira. As above, it is visible to all stakeholders having
access to Jira, but is not prioritized. However, not all
backlog items are transparent, since some are just notes
and thus incomplete. Similarly, Team D stores the entire
product backlog in Jira. It is visible to all stakeholders
having access to Jira, but not prioritized.

D
O
X
X
-X
X
O
X
--

awareness of the product vision (A1, B1, B3, D3).

However, a stronger reason is the company-wide, goaloriented approach, which determines department and
team goals (B1, BC2, C1, D1): We just do not have the
power to get an acceptance for the establishment of an
own product vision (D1, Team D product owner). As
another disadvantage, interviewees state lack of time for
creating and maintaining the written record of the vision,
as they need to focus on daily business (B1, BC2, D1,
D2, D3). Also, a onetime creation of a vision is
insufficient, since a vision requires constant maintenance
due to internal and external influences (A1, AC3).
While all of the aforementioned reasons mainly stem
from the organization in which the teams operate, their
members also stated one reason solely arising from the
team itself, namely the prevalent view that a product
vision is an abstract construct (A1), which constrains
creativity and thinking out of the box (C1).
4.1.2. Product roadmap. A product roadmap is used
in all four teams and covers a period of three months. In
three of the four teams, the product owner initiates its
creation and guides the team by predetermining the key
topics. All team members are subsequently involved in
the creation process by delivering valuable input from
their perspectives. In the fourth team, product owner and
Scrum master prepare a draft of the roadmap and
involve the team in later stages only. In all teams, the
product roadmap is created on a regular basis.
A product roadmap is seen as a medium-term
planning tool, which offers clear goals (AC3, B1, C1,
D2) and thus prepares the team for work in the next
three months (A1, B3, D2). Moreover, it serves as an
internal marketing instrument (D1, D2), helping
illustrate what the teams are working on (A1, C1, B1).
Thus, the product roadmap is a helpful tool for creating
transparency, both within and outside the teams. It
signals reliability (AC3) and helps justify the teams
goals (AC3, BC2, D3): The roadmap is like a wall that
protects the team (D1, Team D product owner).
Despite its application in all teams, disadvantages of
the product roadmap are apparent. The interviewees
frequently mentioned problems related to estimating the

5078

One reason for using a product backlog is the

availability of a central repository for issues that have to
be addressed in the future (AC3, B3, D1, D2).
Moreover, it offers a good basis for planning further
product versions (A1) and thus supports the sprint
planning (B3, D3). In addition, it supports the planning
of smaller work packages (AC3, B1).
However, some teams explain that their product
backlog is too extensive to be completely processed in
the given time (B3, D1). Additionally, product backlogs
are not synchronized with the product roadmap. As a
result, the road map does not reflect the current status of
all recognized issues. Consequently, work time is
sometimes wasted for backlog maintenance (A1).
Finally, in many cases, product backlogs are used as
notepads. In such cases, only the backlog authors can
fully understand what is meant by the entries, which
leads to reduced transparency (C1, D3).
Advocates argue for the backlog items prioritization
as a means of increasing transparency for employees
within and outside the team (BC2, D1). This also makes
the sprint planning more efficient, as the team picks the
highest prioritized backlog items, rather than having to
trawl through the entire backlog (BC2, AC3).
Conversely, time constraints are the main reason for
not prioritizing backlogs (A1, D1, D3). Additionally,
backlogs are quite extensive, leading to effort-intensive
prioritization processes (B1, D1, D3). Prioritization
sometimes raises controversies, as it mainly depends on
the evaluation of the product owner (AC3, B3, D1, D2).
The fact that all stakeholders (not just the team
members) have access to the backlogs increases
transparency inside and outside the team. This
transparency offers an overview of the upcoming topics
for the team (D1, D2) and empowers external
employees, as they can monitor the status of their
feedback (AC3, B1,D3), which makes communication
and stakeholder management more efficient (A1, D1). It
also supports acceptance and valuation of the teams
work in other departments within the company (BC2).
A problem, on the other hand, is keeping the product
backlog in good shape (BC2). This is necessary for
ensuring that stakeholders understand the items
meaning and increases transparency (B1). Additionally,
fears exist concerning issues discussed outside the team
(A1), which results in a challenge to handle stakeholder
feedback in an appropriate way (C1).
4.1.4. Definition of done. In contrast to the
recommendations made in the extant literature (cf.
section 2), none of the four teams applies a common
definition of done. Each team has its own, individual
done criteria on a backlog item level.
Although interviewees admit the importance of
clearly knowing what has to be done to complete a
backlog item (BC2, D3), many also agree that it is not

necessary to have a common definition of done that

covers needs of all teams (B1, D1, D2). In their view,
acceptance criteria on a backlog item level are sufficient
(BC2, C1). Moreover, the knowledge of team members
helps to make the acceptance criteria concrete in cases
when these are not properly prescribed (AC3, BC2).
This, in turn, has the advantage that the acceptance of an
issue can be managed on an individual level (C1).
Finally, developing a common definition of done
simply requires too much effort (AC3, BC2, D2).
4.1.5. Sprint backlog. A sprint backlog is used in all
four teams and changes are made cautiously. Team A
only makes changes to the sprint backlog if additional
requirements arise due to dependencies on other teams.
Team B only adapts the backlog if estimates made at the
beginning of the sprint are inaccurate. However, it
explicitly never enhances the sprint backlog. In case of
Team C, the backlog is only adapted if requirements
were not clear at the beginning of a sprint, or the
complexity of specific topics was underestimated.
Finally, Team D changes the backlog if ad-hoc
requirements occur, bugs are reported, or in order to
make inaccurate planning more specific.
The advantages and thus the reason for using a sprint
backlog are clear to the interviewees. Elaborating,
estimating, and assigning the backlog items to the sprint
backlog encompasses assignments of tasks to team
members and external resources, gaining their
commitment, and scheduling due dates (A1, C1, D1,
D3). The prioritization yields knowledge about what has
to be done and in which order (D3). Additionally, it is
possible to control the progress during the sprint, since
all items are updated/tracked in the sprint backlog (C1,
D1), leading to transparency (A1, AC3). Finally, using a
sprint backlog enables using electronic tools (like Jira)
to manage the backlog and enhance efficiency (AC3).
Conversely, there are almost no disadvantages, with
the exception of over-planning (i.e., the planning of too
many backlog items for a sprint) that can lead to
overheads (D3) decreasing team members motivation.
Among the recognized advantages of adopting the
sprint backlog, most notable are higher flexibility (D1,
D2, D3) and greater stakeholder satisfaction, if
additional tasks can be completed in a short time (D3).
However, some disadvantages of adopting a sprint
backlog are also noted by the interviewees. For example,
enhancing the backlog can lead to time pressure for
team. It can also reduce output quality as, for instance,
insufficient testing capacities are available (AC3, D3).
It can also cause a reduction in the overall
development speed, as introducing new topics requires
time and resources (D3). Finally, discomfort inside the
team increases, resulting in decreased motivation (AC3).

5079

do not have a strong impact on the teams work (AC3).

Daily Scrums help the team to check the status of
backlog items on a daily basis (D1) and thus keeps the
team focused (B1, C1). Moreover, they serve as a
reminder (D1) and foster the transparency of the work
progress (A1) as well as communication and interaction
(BC2) within the team. Daily Scrums are a source of
new ideas (B1) and lead to better team spirit (B1, C1).
Among the disadvantages the interviewees noted,
time constraints lying outside the teams influence are
the main reason for not conducting these meetings on a
daily basis. Three of the four teams do not have the time
for conducting the daily meetings (BC2, D2, AC3, D1),
especially in cases when some team members are
assigned to more than one team at the same time (BC2).
Thus, the reasons for not conducting Daily Scrums
mainly stem from the organization. However, work
progress might not be sufficient to require additional
updates (D2, B3, B1).
Daily Scrums take place at the same time and place
in all four teams to avoid confusions caused by
organizational matters (BC2, A1) and to minimize
coordination efforts (D2, C1, AC3).
A disadvantage, on the other hand, is that team
members from other departments require higher effort
for coming to the meeting rooms in the basement (BC2).
If topics cannot be clarified in Daily Scrums, only
the members that can contribute to the topics discussed
are invited to additional meetings. This prevents wasting
resources (A1, AC3, D2, D1, D3) and preserves
motivation for the Daily Scrum (D2, BC1). No
disadvantages related to Daily Scrums were mentioned.
4.2.3. Sprint review meeting. Such meetings are
conducted on regular basis by two teams (in one team,
this activity is combined with the sprint planning
meeting). Another team has conducted it twice since the
implementation of Scrum. The remaining team has not
performed such a meeting yet but is currently thinking
of its implementation. Customer participation in such
meeting is generally rare. Arguments for conducting a
sprint review meeting are that it creates awareness for
conducted work (AC3, B1, D1, D2) and results in
increased motivation of the team members (D1, D2).
Furthermore, feedback is collected (B3) and areas for
product improvements are identified (D1, D2, D3).
Although not strictly a meetings core purpose, status
and performance of the sprint work can be assessed
(D3). As a result, problems (C1) and lessons learned
(A1, C1) during the development process are exposed,
which is particularly important if a team does not
conduct a sprint retrospective meeting (see 4.2.4).
Despite its advantages, the majority of the interviewees
cite the time dedicated to the sprint review meeting as an
issue (A1, AC3, D1, D2), which stems from external
time pressures. This applies to both the time required to

4.2. Events
4.2.1. Sprint planning meeting. This principle is
applied by all teams at the beginning of each sprint, that
is, every two weeks. The meeting usually takes about
one to two hours and, while all team members are
involved, other stakeholders are not.
The main reasons for conducting sprint-planning
meetings are related to planning (B1, AC3, D3), in
particular, determining responsibilities (D1, C1) and
estimating effort (C1, D1, AC3) by creating the sprint
backlog. Additionally, the meeting fosters common
commitment (B1) to the tasks for the next sprint. The
team aligns itself (D3) to the goals that must be
achieved. Accordingly, and due to the fact that team
members take tasks on a voluntary basis, a kind of team
spirit emerges, which leads to increased team motivation
(B1). Other advantages mentioned are planning certainty
(D1), goal-orientation (A1), and ensuring that each team
member is working to capacity (BC2).
However, such meetings sometimes take longer than
necessary (B1) since, in most teams, effort estimation
for all tasks is conducted solely during this meeting.
According to the interviewees, all team members
participate in each sprint-planning meeting, primarily
because this increases motivation (D2, D3, BC2, AC3).
Each team member has the feeling that he or she can
decide upon the direction the team will be working in
the next sprint. Sprint planning meetings also foster
transparency, since each team member is aware of the
upcoming tasks (AC3, A1, BC2). Thus, communication
efforts are reduced (D2). Furthermore, the meetings help
new team members to be quickly integrated into the
team (D1). Finally, everyone has specific qualities that
he or she can contribute to the team in order to reach the
best possible planning outcome (B3, D2).
These advantages notwithstanding, several pitfalls
were mentioned to occur in daily work. These mainly
concern the time efforts (B3, Ac3, D2, C3), which are
considered comparatively high, especially for team
members who do not work full-time in the team (A1,
AC3, D3). As it is not necessary for each team member
to be familiar with every task, the meeting is not
universally important to everyone (BC2, D1).
4.2.2. Daily Scrum. The daily meeting is arranged
by one of the four teams only. However, the other three
teams also conduct regular meetings, but only two or
three times a week. In each case, the meeting takes place
at the same time and place and lasts about 15 minutes.
Due to the limited time, topics requiring more extensive
discussion are postponed to other meetings.
In general, our interviewees consider this regular
meeting positive. For example, many smaller issues can
be discussed in a quick manner (D2, AC3, A1) and
uncertainties can be disclosed (C1, BC2). Thus, problems

5080

However, products must allow to be developed in

encapsulated iterations. In one of TrustMeCorps teams,
the implementation of such iterations was challenging,
since a more holistic approach was necessary in some
cases (D1). Finally, when introducing scrum teams, the
company has to be aware of the need for a set-up phase,
which is necessary to become familiar with the product
and Scrum itself (BC2).
Concerning advantages or disadvantages of spatial
proximity of the team, the majority of the interviewees
argued for sharing office space with other team
members, instead of having only functional
representatives in close proximity (A1, AC3, B1, C1,
D1, D2, D3). One of the advantages of such an
arrangement is faster interaction with other team
members (A1, AC3, B1, D1, D2). Some interviewees
state that this is especially important for developers, as
they need to be able to exchange technical information
(C1, BC2). Moreover, it fosters the social contact with
other team members (D1) and thus has an important
team-building function.
Disadvantages, or rather challenges, pertain to the
need to create a seating plan that merges team members
but also offers connections to other teams and functions
(C1). This may not always be possible in the office
space available.
4.3.2. Product owner. Each Scrum team in our case
company has a product owner. The four product owners
perform their role in a manner similar to that described
in the pertinent literature. However, there are minor
adaptations. The product owner of Team B is also
involved in implementation and testing. Therefore, the
Scrum master supports the product owner when it comes
to the maintenance of the product backlog. The product
owner of Team D is practically in charge of two
products, but does not maintain the product backlog and
the backlog items. Additionally, the product owner of
Team C acts in line with the published
recommendations, but fulfills two roles at the same time,
since he is also the chief product owner (cf. section
2.3.3). Except for these adaptations, all interviewed
product owners closely collaborate with the Scrum
masters of their teams and try to integrate the team
members into this process.
The reason for the close collaboration is the better
outcome of the work process (B1). The chief product
owner adds: Both have to be a well-functioning team
who get along with each other (C1, Team C chief
product owner). Our interviewees did not mention any
disadvantages concerning this collaboration.
While a close collaboration of the product owner
with other team members is seen as important for the
team, it can also lead to too many distractions (D1).
When it comes to decision-making, advantages of
involving the entire team include the opportunity to ask

hold the meeting itself and the time spent preparing the
presentation of the results (AC3). Despite potential
benefits, such as reduced communication effort (A1,
AC3, D2) and direct customer feedback (A1, AC3, D2),
customers are typically not invited to the review
meetings. Our interviewees see increased time effort due
to a greater number of participants and too many
discussions on a content level (A1, AC3, B2) as factors
that threaten the success of such meetings.
4.2.4. Sprint retrospective meeting. One team
conducts sprint retrospective meetings on a regular
basis. Another team has conducted it twice since the
implementation of Scrum. The remaining two teams
have not performed such a meeting yet. As a positive
experience and thus as an argument for conducting a
sprint retrospective meeting, members of Team A and B
mention that its main advantages are the ability to
discuss and clarify problems within the collaboration
process. Respective solutions can be directly
implemented in the next sprint (AC3, BC2). Moreover,
members of Team B reported no fear of contact (B2).
Discussion takes place in an organized way (D2) and
improvements are proposed and agreed upon by the
team itself (B1, B2, D2). However, the main reason for
omitting this meeting is extensive effort (A1, C1, D2,
D3) related to the time pressure dictated from outside
the team. Instead, informal talks take place, although
experiences have shown that these are not as efficient as
structured meetings (D1). Team A and B also consider
combining sprint retrospective meetings with the sprint
review meetings to save time (A1, B3).

4.3. Roles
4.3.1. Scrum team. Since Scrum cannot be applied
without a Scrum team, all four teams have a core Scrum
team, which develops the product features (cf. section
2.3.1). As already described in section 2.3.1, the four
Scrum teams have on average eight members (Team A:
eight, Team B: eight, Team C: seven, Team D: nine).
In comparison to common project teams, Scrum
teams in product management are advantageous, since
they focus on one dedicated product and thus possess
higher expertise and knowledge with regard to this
product (A1, AC3, B1, BC2, C1, D2, D3). The regular
and constant cooperation in a stable team offers
opportunities for enhancing product knowledge and
ensure a steep learning curve, which increases
effectiveness and efficiency (A1, BC2, D2, D3). Teams
can work on products on an unlimited time horizon (B1,
BC2, D1, D2). The small teams also facilitate quicker
development of features (AC3, B1, C1, D3) and can
improve individual team dynamics (BC2). Additionally,
less overhead is required for planning and internal
marketing compared to normal project organization (C1).

5081

experts for input pertaining to the topics within their

field of expertise (A1, D1), the increased likelihood of
the team backing the decision (A1), and increased
motivation (C1).
4.3.3. Scrum master. Three of the four Scrum teams
have a Scrum master. Besides the responsibilities stated
in literature, the three Scrum masters are also involved
in other roles tasks. They also closely collaborate with
the product owners. A reason for the extended field of
action is that the company prefers that the Scrum
masters not assume the classical role (A1). As a result,
they can, for instance, support the team more efficiently,
as they are more familiar with the impediments other
team members face (A1, B1). Disadvantages regarding
this extended field of action were not mentioned.
According to the Scrum masters we interviewed, the
benefits of the close collaboration with the product
owner include (1) signaling the willingness to work as a
unity (i.e., inside the team as well as with colleagues
from other teams) (A1, D2) and (2) confirming that the
team can rely on the statements of both roles (D2).

the product teams from developing their own product

visions. While contradicting one of the fundamental
principles, the application of Scrum at TrustMeCorp
suitably fits the companys culture. Though other cases
(e.g., [1]) have shown a monthly determination of
product vision to be helpful, our case setting shows that
the task of developing and maintaining product vision
can be transferred from product team level to company
level (see 4.1.1). The above discussion of the product
vision principle shows that its adoption depends on the
broader context of the case company. Thus, when
interpreting the results reported here, one must be aware
that not all design decisions could freely be made by the
teams. Some external impediments may arise, for
instance, in the surrounding organization, and thus limit
the teams in their design alternative (e.g., time
constraints making it hard to conduct retrospective
meetings on a regular basis). However, by giving a
detailed account of the motives behind the design
decisions (cf. the description of our interview results and
observations in section 4), we aimed to show the
decisions root causes.
Shifting our attention to sprint meetings shows that
adoptions can also be contingent on team context.
Considering the four teams (cf. Table 2), no pattern of
applying the principles sprint review meeting and sprint
retrospective meeting can be discerned. Rather, the
decision to fully apply or partially adapt one of the
principles seems to primarily depend on time required to
conduct the meetings. Concerning both principles, our
interviewees explained that the meetings themselves, as
well as their preparation, are too time-consuming (see
4.2.3 and 4.2.4). Given the importance of the review
meetings [1, 5, 16], neglecting the respective principles
is surprising. An explanation can be found in the time
constraints in our case company, which can be seen as
extreme due to increased overhead for meetings
associated with the relatively short cycle times (two
weeks). The TrustMeCorp teams, however, see the
benefits of the meetings and try to work out a practical
solution by merging sprint retrospective meetings and
sprint review meetings (see 4.2.4). The Daily Scrum has
been previously identified as a positive, helpful aspect
of the process, which assists in avoiding potential
problems and solving existing problems through the
provision of constructive critique [1, p. 69]. While the
general concept of the meeting is applied across all
teams, and our interviewees confirm the benefits of such
meetings, only one of the four analyzed teams at our
case company actually uses the Daily Scrum as
intended. The interval of the meetings is contingent on
the team context. In cases where employees are assigned
to several teams at the same time, daily meetings in each
of the teams would lead to severe constraints on behalf
of those employees. Furthermore, teams at our case

5. Discussion
Our case study yields insights into the application
and adoption of Scrum principles in the context of
product management. Our findings indicate that not all
Scrum principles are suitable in each context. This
assertion is in line with research based on the
contingency approach [3033], which deems the
universalistic one size fits all approach inadequate.
While the latter stems from the early years of project
management [34] and treats organizations and projects
as fundamentally similar to each other [35], the former
suggests the most effective approach to account for
given contingencies [36]. While decisions based on
contingency theory, on an abstract level, pertain to, for
instance, the general choice between sequential and agile
development approaches, our results suggest that
contingency approaches also apply to fine-grained
decisions within the field of agile development.
Scrum principles are widely adapted at
TrustMeCorp. Only three principles are fully applied by
all four teams at our case company (cf. Table 2). In the
following, we discuss selected principles contingent to
the setting of TrustMeCorp, as well as the reasons for
their adaption in light of extant research. While
none of the product teams formulates a product
vision in a written form thus contradicting suggestions
in literature to make the product vision visible [16, p.
24] the context of TrustMeCorp defines the necessity
to neglect this principle. In general, a common
understanding exists concerning the products goals and
strategies. However, the companys goal-oriented
approach to the work of departments and teams prevents

5082

[12] K. Conboy, Agility from First Principles: Reconstructing the

Concept of Agility in Information Systems Development,
Information Systems Research, vol. 20, no. 3, pp. 329354, 2009.
[13] G. Lee and W. Xia, Toward Agile: An Integrated Analysis of
Quantitative and Qualitative Field Data on Software Development
Agility, MIS Quarterly, vol. 34, no. 1, pp. 87114, 2010.
[14] T. Dingsyr, T. Dyb, and P. Abrahamsson, A Preliminary
Roadmap for Empirical Research on Agile Software Development, in
Agile Conference, Los Alamitos: IEEE, 2008, pp. 8394.
[15] P.J. gerfalk, B. Fitzgerald, and S.A. Slaughter, Introduction
to the Special Issue - Flexible and Distributed Information Systems
Development: State of the Art and Research Challenges,
Information Systems Research, vol. 20, no. 3, pp. 317328, 2009.
[16] R. Pichler, Agile Product Management with Scrum. Creating
Products that Customers Love, 4th ed. Upper Saddle River: AddisonWesley, 2011.
[17] W. Royce, Managing the Development of Large Software
Systems, in Papers presented at the Western Electronic Show and
Convention, 1970.
[18] J. Sutherland and K. Schwaber, The Scrum Papers. Nuts, Bolts,
and Origins of an Agile Method. Boston, 2007.
[19] R.K. Yin, Case Study Research. Design and Methods. Thousand
Oaks: Sage, 2009.
[20] G. Par, Investigating Information Systems with Positivist
Case Study Research, Communications of the Association for
Information Systems, vol. 13, no. 18, pp. 233364, 2004.
[21] K.M. Eisenhardt, Building Theories from Case Study
Research, The Academy of Management Review, vol. 14, no. 4, pp.
532550, 1989.
[22] A.S. Lee, Integrating Positivist and Interpretive Approaches to
Organizational Research, Organization Science, vol. 2, no. 4, pp.
342365, 1991.
[23] W.J. Orlikowski and J.J. Baroudi, Studying Information
Technology in Organizations: Research Approaches and Assumptions, Information Systems Research, vol. 2, no. 1, pp. 128, 1991.
[24] I. Benbasat, D.K. Goldstein, and M. Mead, The Case Research
Strategy in Studies of Information Systems, MIS Quarterly, vol. 11,
no. 3, pp. 369386, 1987.
[25] M.B. Miles and A.M. Huberman, Qualitative Data Analysis.
Thousand Oaks: Sage, 1994.
[26] A. Malhotra, A. Majchrzak, R. Carman, and V. Lott, Radical
Innovation without Collocation: A Case Study at BoeingRocketdyne, MIS Quarterly, vol. 25, no. 2, pp. 229249, 2001.
[27] J.Y.H. Lee and N. Panteli, Business strategic conflict in
computer-mediated communication, European Journal of
Information Systems, vol. 19, no. 2, pp. 196208, 2010.
[28] M.Q. Patton, Qualitative Research & Evaluation Methods, 3rd
ed. Thousand Oaks: Sage, 2002.
[29] A. Coffey and P. Atkinson, Making Sense of Qualitative Data:
Complementary Research Strategies. Thousand Oaks: Sage, 1996.
[30] B. Hanisch and A. Wald, A Bibliometric View on the Use of
Contingency Theory in Project Management Research, Project
Management Journal, vol. 43, no. 3, pp. 423, 2012.
[31] J. Woodward, Management and Technology. London: Her
Majestys Stationary Office, 1958.
[32] T. Burns and G. Stalker, The Management of Innovation.
London: Tavistock, 1961.
[33] P.R. Lawrence and J. Lorsch, Organization and Environment:
Managing Differentiation and Integration. Boston: Harvard Business
Press, 1967.
[34] D. Dvir, S. Lipovetsky, A.J. Shenhar, and A. Tishler, In Search
of Project Classification: A Non-Universal Approach to Project
Success Factors, Research Policy, vol. 27, no. 9, pp. 915935, 1998.
[35] F. Taylor, The Principles of Scientific Management. London:
Harper & Brothers, 1911.
[36] J. Tidd, Innovation Management in Context: Environment,
Organization and Performance, International Journal of
Management Reviews, vol. 3, no. 3, pp. 169183, 2001.

company emphasize that sufficient progress needs to be

made for a useful discussion. While our results thus
corroborate the criticality of regular meetings in which
the entire product team takes part in order to discuss a
projects current state, the team context also shows that
such meetings do not have to take place on a daily basis.

6. Conclusion
With our study of how Scrum principles are applied
in practice, we answer the call for empirical research
concerning adoption of agile methods. While showing
that customizing the core principles is perceived as
beneficial by practitioners, we argue that Scrum
principles are contingent on the context they are applied
to. By discussing the reasons for adopting or adapting
the principles, we contribute to a deeper understanding
of agile methods in practice and help to open the black
box of development approaches in information systems
research. While our study can be seen as a starting point
for quantitative evaluations of contingency theory in the
context of agile development, the in-depth insights of
Scrum principles at TrustMeCorp provide practitioners a
useful reference for adapting agile methods to the
context of their companies.

7. References
[1] K. Vlaanderen, S. Jansen, S. Brinkkemper, and E. Jaspers, The
Agile Requirements Refinery: Applying SCRUM Principles to
Software Product Management, Information and Software
Technology, vol. 53, no. 1, pp. 5870, 2011.
[2] A. Marchenko and P. Abrahamsson, Scrum in a Multiproject
Environment: An Ethnographically-Inspired Case Study on the
Adoption Challenges, in Agile Conference, 2008, pp. 1526.
[3] T. Dingsyr, S. Nerur, V. Balijepally, and N.B. Moe, A Decade
of Agile Methodologies: Towards Explaining Agile Software
Development, Journal of Systems and Software, vol. 85, no. 6, pp.
12131221, 2012.
[4] M. Hummel, C. Rosenkranz, and R. Holten, The Role of
Communication in Agile Systems Development. An Analysis of the
State of the Art, Business & Information Systems Engineering, vol.
5, no. 5, pp. 344355, 2013.
[5] K. Schwaber and M. Beedle, Agile Software Development with
Scrum. Upper Saddle River: Prentice Hall, 2002.
[6] M. Pichler, H. Rumetshofer, and W. Wahler, Agile
Requirements Engineering for a Social Insurance for Occupational
Risks Organization: A Case Study, in International Requirements
Engineering Conference, 2006, pp. 251256.
[7] P. Abrahamsson, O. Salo, J. Ronkainen, and J. Warsta, Agile
Software Development Methods: Review and Analysis: VTT
Technical Report, 2002.
[8] B. Fitzgerald, G. Hartnett, and K. Conboy, Customising Agile
Methods to Software Practices at Intel Shannon, European Journal
of Information Systems, vol. 15, no. 2, pp. 200213, 2006.
[9] L.A. Ika, Project Success as a Topic in Project Management
Journals, Project Management Journal, vol. 40, no. 4, pp. 619, 2009.
[10] K. Siau, Y. Long, and M. Ling, Toward a Unified Model of
Information Systems Development Success, Journal of Database
Management, vol. 21, no. 1, pp. 80101, 2010.
[11] R.R. Tan, Success Criteria and Success Factors for External
Technology Transfer Projects, Project Management Journal, vol.
27, no. 2, pp. 4556, 1996.

5083