=Paper=
{{Paper
|id=Vol-3272/paper5
|storemode=property
|title=Tailoring Choices Made in Scrum Projects: A Systematic Literature Review
|pdfUrl=https://ceur-ws.org/Vol-3272/IWSM-MENSURA22_paper5.pdf
|volume=Vol-3272
|authors=Özgün Özkan,Özden Özcan-Top
|dblpUrl=https://dblp.org/rec/conf/iwsm/OzkanO22
}}
==Tailoring Choices Made in Scrum Projects: A Systematic Literature Review==
https://ceur-ws.org/Vol-3272/IWSM-MENSURA22_paper5.pdf
Tailoring Choices Made in Scrum Projects: A Systematic
Literature Review
Özgün Özkan, Özden Özcan-Top
Graduate School of Informatics, Middle East Technical University, Ankara, Türkiye
Abstract
Among various Agile Software Development (ASD) methods, Scrum is one of the most widely
adopted ones. The Scrum Guide gives a clear description of the Scrum practices, artifacts, and
roles. However, due to various project characteristics such as team size, team distribution,
project domain, technology, and requirement stability levels, Scrum practices need to be
tailored. In this study, we performed a Systematic Literature Review to understand how
software development companies adopt Scrum into their contexts, and explore the tailoring
choices made in Scrum practices, roles and artifacts. The results of this SLR show that most
organizations tailor the existing Scrum components by either not implementing a specific
practice, role, or an artifact or modifying the duration limits of the practices. We specified that
there are limited number of studies reporting successful Scrum adoptions. Most of the studies
in our paper pool report that the tailored Scrum components cause difficulties in getting
customer feedback on time, not understanding the sprint goal well enough, having an
unordered, unclear product and sprint backlog, and an increase in project failures.
Keywords 1
Agile, Scrum, tailoring, customization, Scrum adoption
1. Introduction
The need for developing higher quality products efficiently and managing changes with adaptable
and harmless ways led practitioners to adopt new approaches in software development [1]. Agile
Software Development (ASD) was introduced as an alternative to traditional approaches (e.g. Waterfall
and V-Model) to overcome certain challenges such as overwhelming documentation, and inability to
respond to changes quickly and sustainably [1]. In 2001, software practitioners introduced the Agile
Manifesto and presented a novel software development philosophy [2]. Since then, several methods
that share the Agile values and principles have been published. Scrum, XP, Kanban, and Disciplined
Agile Delivery methods can be listed among these methods. Due to various factors such as team size,
team distribution, project domain, budget and duration, requirement stability, stakeholder availability,
legal aspects, and contract types, organizations have to tailor their processes compared to the original
definition of the software development methodologies to achieve business goals [5]. In this study, we
explored one of the most widely used ASD methods, the Scrum, from the tailoring choices perspective
with a Systematic Literature Review [11]. Our motivation is based on the fact that some of the Scrum
tailoring choices may be incorrect and may cause inefficiencies in software development and project
failures. The Scrum method defines practices, roles, and artifacts which we call as the Scrum
components in the rest of the paper. We performed the SLR to specify the tailored Scrum components
in software projects and understand to what extent these components are tailored. We also explored the
positive and negative consequences of the tailoring choices and the evidence reported by the
researchers. To specify the tailoring choices made, we referred the original definitions given in the
Scrum Guide [6]. Aligned with these purposes, we defined the following research questions:
Proceedings Name, Month XX–XX, YYYY, City, Country
EMAIL: ozgun.ozkan_01@metu.edu.tr (A. 1);
ozdenoz@metu.edu.tr (A. 2);
ORCID: 0000-0001-6608-0726 (A. 2)
©️ 2020 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
RQ1: Which components (practices (events), roles and artifacts) of the Scrum method are tailored?
In what way are they tailored?
RQ2: What are the positive and/or negative evidence for the tailoring choices? This study
contributes to the literature with a comprehensive review of the Scrum components from the tailoring
perspective. We believe that the results could be used both by researchers and practitioners to make
better decisions in Scrum tailoring. The rest of the paper is structured as follows: Section 2 includes a
Related Work section that shows the literature studies about Scrum Tailoring. Section 3 shows our
methodology to conduct this SLR, including the search strategy, paper selection criteria, and the quality
assessment process. Section 4 shows the result of the SLR, and Section 5 presents the conclusion of our
work, the limitation of the study, and future suggestions for both researchers and practitioners.
2. Related Work
In this study, we are interested in the concept of tailored Scrum components such as variations in
implementing practices, roles and artifacts, and the consequences of the tailoring choices. When we
explored the literature, we found three previously published systematic literature review [5][7][8] and
two systematic mapping [9][10] studies that focus on different perspectives of Scrum tailoring or
software process tailoring. We found out that previous literature review studies [5][7][8][9][10]
generally focus either on the tailoring criteria for software development projects, or challenges and
motivations for Agile tailoring [5][7][8]. Hron and Obwegeser [7] in an SLR study, report the
challenges and motivations for companies that want to tailor the Scrum method. In this paper, it was
stated that considering the 31 relevant studies, seven factors motivating teams to tailor Scrum practices
were reported: working in distributed settings, combination with other methods, increased requirements
for UX and usability, vertical scaling, size scaling, tools and adoption to different context. Additionally,
six solution strategies for achieving these goals were identified as pre-development, introduction of new
procedures/artifacts/roles, providing method guidance, multiplicity of some method elements, and
developing specific tools [7]. Kalus and Kuhrmann [5] perform an SLR in which they present a
collection of 49 tailoring criteria which are later linked to a set of 20 exemplary tailoring actions.
Campanelli and Parreiras [8] conducted another SLR on agile methods tailoring including the adopted
method tailoring approaches and tailoring criteria such as project type, complexity, team size and
technology knowledge. In this study, research and technical aspects of the agile method tailoring from
the literature and possible research areas were provided in detail. Diebold and Dahlem [9] conducted a
mapping study on agile practices in the industry which are used in different contexts and circumstances.
In this study, practices were classified as fully used, partially used and not used which give an overall
understanding of the usage prevalence of specific agile practices. Jovanovic et al. [10] provides a
systematic mapping of available frameworks, issues and factors to identify different aspects of agile
transition. These SLR and SM studies mentioned above helped us gain insights into the conditions that
arise Scrum tailoring needs, challenges encountered in tailoring Scrum, and solution strategies to adopt
Scrum in different contexts. However, these studies do not provide clear explanations on how the Scrum
practices, roles and artifacts are tailored in the literature. Our study differs from prior work in two main
aspects: (i) it focuses on the specific Scrum component tailoring examples from the industry in a
detailed manner and (ii) it provides positive and negative consequences of the tailoring choices made.
3. Research Methodology
This study uses a well-defined methodology to answer all of the research questions given in the
Introduction Section.
Among the various resources for conducting an SLR, we followed the Kitchenham and Charter’s
guideline [11]. Fig. 1 illustrates the overall flow of our SLR process.
Fig. 1 Steps of our SLR process
3.1 Research Goal and Research Questions
The main goal of this paper is to determine, analyze and synthesize the scientific papers about the
tailoring of Scrum practices, roles and artifacts and the positive/negative evidence for the tailoring
choices. The search period starts in 2001 as it is the year in which the Agile Software Development
manifesto was published and ends in 2022.
3.2 Paper Selection Strategy
The paper selection strategy included the following stages:
3.2.1 Decision of the main data sources and the search process
To find related papers, we decided to use four online academic paper search engines: (1) IEEE
Explore, (2) ACM Digital Library, (3) Scopus, and (4) Springer. To find as many relevant studies
as possible, we identified the search keywords with an iterative approach, by exploring alternative
keyword options and formulated final query as follows:
(Agile Tailoring OR Agile Practice Tailoring OR Agile Process Tailoring OR Scrum Process
Tailoring OR Scrum Adaptation OR Scrum Tailoring)
3.2.2 Deciding and applying the inclusion and exclusion criteria
Since the main focus of our study is on exploring how the Scrum method is tailored, the studies
which are not related to our topic were excluded as the first step of filtering the search results by reading
the titles, abstracts and keywords of the studies. When we get the initial results, we noticed that all of
the papers after some point were irrelevant to our topic. Thus, we did not need to check for the rest of
the results for 13962 papers and apply the same inclusion/exclusion criteria each time. After the
evaluation of the papers based on the titles and abstracts, we accessed 56 papers. For the studies that
were still not clear after this process we read whole papers. Additionally, we only included the studies
written in English. As the final filtering approach, we evaluated the papers based on the quality
assessment questions given below:
1. Is the conference where the study was published has at least B ranking2 ? (Conferences that have a
ranking of A and B were accepted).
2. Are the goals of the research clearly stated?
3. Were the participants of the study appropriately selected? (Is there anything that violates the
soundness of the research applied?)
4. Are the data collection methods adequately described?
5. Has the context of the study been explained?
6. Is there a valid research design to address the aims of the project?
7. Was the data analysis carried out rigorously?
8. Is there a clear statement of results?
9. Does at least one of the research questions receive their answers?
10. To what extent the paper is related to our topic?
We rated each study on a scale of 3 for each question (except for the 1st one) and eliminated the
ones that receive 1 in any of the quality criteria (i.e. 1 corresponds to weak, 2 corresponds to medium,
and 3 corresponds to good). The number of the papers in our paper pool was decreased to 19 after the
quality assessment process. To make sure that we do not miss any relevant studies that can contribute
to our research, we also used the snowballing technique by browsing through the references section of
each paper. We found four additional papers with the snowballing technique.
In Table1, the number of search results after each of the filtering stage is presented.
3.2.3 Data Extraction
To answer the research questions, we extracted the following data: the type of the paper, context of
the paper, tailored practices, tailored Scrum role and the ways these Scrum components were tailored.
2
Schauerte, Boris. “Conference Ranks.” Conference Ranks, http://www.conferenceranks.com/.
Online Initial Evaluation Evaluation Snow- Final
Library Results based on based on Balling Results
titles and Quality
abstracts Criteria
IEEE 55 15 4 - 4
Xplore 45
Scopus 56 18 10 1 11
8
Springer 33 9 2 1 3
93
ACM 44 14 3 2 5
Digital 56
Library
Total 13 56 19 4 23
962
TABLE 1. The results of the paper evaluation process
The final paper pool includes 23 papers ,13 of which were published in conference proceedings whereas
10 of the papers were published in journals. In the rest of this SLR, these final set of papers have been
used to present the results of the Scrum tailoring approaches. Additionally, each set of studies have
been mapped to particular research question in results section to provide more detail about the impact
of each tailoring choice.
4. Results
In this section, we presenet the results of our SLR study.
4.1 RQ 1.1-Tailored Scrum Practices and Tailoring Choices
When we analyzed the SLR data, we specified that the most preferred tailoring approach is either
not using a specific Scrum practice at all or not properly following the rules defined in the Scrum Guide
for that specific practice [6]. Among 23 papers, 8 distinct papers contain Scrum practice tailoring
examples applied in various domains [3][4][7][12][13][14][15][16]. We specified that the Sprint ,
Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective are the practices tailored.
Fig2. shows the distribution of the number of papers per specific tailored Scrum practices. It can be
deducted that most reported practice is Sprint Review which is followed by the Daily Scrum, Sprint
Planning and Sprint Retrospective practices.
Sprint
Sprint Retrospective
Daily Scrum
Sprint Review
Sprint Planning
0 1 2 3 4 5 6
Number of papers
Fig. 2 Tailored Scrum Practices
Below, we explain how the Scrum Practices mentioned above are tailored.
Hossain et al. [14] and Eloranta et al. [13] state cases that Sprint review (SR) meetings were not held
at all. In some cases, the outcome of sprints is only reviewed by QA teams rather than an overall
evaluation of the outcome by development team and other stakeholders[14]. In another company, only
Scrum Masters, Project Manager and Customers are involved in Sprint Reviews not development team
members due to one team being too small and the other one being too large[14]. Although project
management role is more attributed to traditional/plan-driven project management approaches, this
study is an indication of having a project manager role in Scrum projects. Another approach to the
Sprint Review tailoring is to conduct more than one Sprint Review meetings for each iteration. For
example, as stated by Diebold et al. [4], two companies have a strategy to conduct two review sessions:
an internal session with developers to review the results, and a second review session to include other
stakeholders particularly the customer. The reason is stated as the team has the possibility to make some
adjustments based on the first feedback before customer sees the final result. Fig. 3 shows the
distribution of the various types of Sprint Review tailoring in multiple papers.
More than one review for single
sprint
Does not include demo of the
work
Developers are not involved
No Sprint Reviews
0 1 2 3
Number of papers
Fig. 3 Type of Sprint Review Tailoring Choices
Additionally, it has been detected that in the majority of the examples where the Sprint Review practice
is tailored, the Sprint Retrospective practice is also tailored [4][13][14]. It was stated by Eloranta et al.
[13] that in some companies, no Sprint Retrospective meetings were organized as the teams have
insufficient understanding of agile development and Scrum. On the other hand, it was also reported that
the sprint retrospective meetings are organized to finish discussions around 15 minutes. This short
duration preference leads to not being able to run efficient discussion and identify actionable
improvement items. There are also cases, not implementing the sprint retrospective meetings at all or
rarely implementing them [4][14]. Fig. 4 shows the distribution of the types of Sprint Retrospective
tailoring choices reported in different sources. In this context, keeping the Sprint retrospective durations
short or not organizing any retrospectives at all, may lead to negative results for the organizations. In
other words, these tailoring choices, contradict with Scrum Guide [6] and can be considered as false
tailoring examples.
Too short retrospectives
Rare/No Retrospectives
0 0,5 1 1,5 2 2,5 3 3,5
Number of papers
Fig. 4 Type of Sprint Retrospective Tailoring Choices
Daily Scrum (DS) is the second most commonly tailored Scrum practice based on the SLR data. The
tailoring choices reported for the Daily Scrum meetings cover the number of meetings that companies
held in each iteration, the duration of DS meetings or the participants involved in DS meetings. Hossain
et al. [14] reports that in distributed projects onshore and offshore teams held daily scrums separately
due to time differences. This finding is reflected in Fig. 5 with the “more than 1 daily scrum” option .
Another frequently made choice for DS is not to limit the DS meeting duration with 15 minutes [15].
Diebold et al. [4] reports that some companies hold the duration of the event around 30 minutes that
result to conduct the event in every two days or only once a week if there is not enough news to share
with the team. There are also teams which do not implement the DS practice or the ones that include
external participants into the DS meetings[7].The distribution of the Daily scrum tailoring choices
reported in different papers is given in Fig. 5 below.
External participants were involved
No daily scrums
Was not held every day
No fixed time
Longer than 15 minutes
More than 1 daily scrums
0 1 2
Number of papers
Fig. 5 Type of Daily Scrum Tailoring Choices
Sprint Planning (SP) and Sprint Retrospective are the third most commonly tailored Scrum practices.
We specified that the tailoring choices made for the SP practice were affected by various factors such
as the number of Sprint Planning meetings that were held and the preferred backlog items for the current
sprint. For example, Fitzgerald et al. [12] states that in one team, two sprint planning meetings were
preferred instead of one. In distributed teams having a pre and post-planning meetings with the onshore
teams before the meeting with the offshore teams is another preferred approach. EnergyInfo held an
additional sprint pre-planning meeting with the purposes of increasing the domain knowledge of
offshore team [14]. CollaborationSoft held weekly Sprint Planning meeting with project manager and
sub-team coordinators and TestSoft held an additional Sprint pre-planning meeting by separating the
participants of each meeting (only the product owner and Scrum master join the first planning meeting)
[14]. Considering another Sprint planning tailoring, Mortada et al. [15] states that in an example Sprint
Planning tailoring, teams only used Sprint Backlog during the Sprint Planning meeting. Additionally,
there are cases which report lack of defining a clear Sprint Goal for each Sprint. Depending on these
results, the type of Sprint planning choices can be listed as having more than one sprint planning
meeting, using only sprint backlog for sprint planning, not setting a sprint goal for the sprint, and not
estimating the stories.
In another two studies, there are also examples of companies which tailor the Sprint. For example,
Fitzgerald et al. [12] reports that one of the case companies do not use Sprint time boxing. Instead, they
continue distributing the tasks until the duration of the sprint is at most 20 working days. Fitzgerald et
al. [12] and Eloranta et al. [13] report that having sprints longer than one month is another choice made
regarding the Sprint duration. In summary, the Sprint tailoring in the studies can be listed as having no
sprint at all, having sprints longer than one month, and not having time boxing for the sprints.
4.2 RQ1.2 Tailored Scrum Roles and Tailoring Styles
Development Team
Scrum Master
Product Owner
0 1 2 3 4 5 6
Number of papers
Fig. 6 Type of Scrum Role Tailoring Choices
Among the 23 studies, the most commonly tailored Scrum role was specified as the Product Owner
role which is followed by Scrum Master and Development team roles. Based on the results, the most
common way of tailoring the Product Owner role is assigning other tasks to product owners such as
business analysis, technical management [3]. The cases were reported that customer representatives,
business experts, project managers and Scrum Masters work as POs in Scrum projects [4][13][16]. The
second most common way of tailoring the Product Owner role is not having a Product Owner in the
team at all or having multiple product owners within the same team. Based on the definition of the
Product Owner role given in the Scrum Guide, every Scrum team needs to have a Product Owner and
that person cannot have the role of Scrum Master [6].
The final approach to tailoring the Product Owner role that was found is assigning a Proxy Product
Owner role. This role, can be considered as a role that can replace the real product owner when the PO
is not available [16].
Fig. 7 shows the distribution of the tailoring choices of the Product Owner role reported in the studies
in our paper pool.
Proxy PO
Multiple PO
No PO
PO has other
responsibilities
0 1 2 3 4 5
Number of papers
Fig. 7 Type of Product Owner Role Tailoring Choice
For the Scrum Master (SM) role, the most reported tailoring choice is to not have a SM role in projects
or having other roles (e.g. business analyst) act as SM. Masood et al. report that the reason why Scrum
teams do not have a SM role is that these team considered themselves mature enough and see no reason
to have a dedicated SM [3]. In another study, companies fill this role with an existing Project manager
or a team lead or a developer who acts as Scrum Master. Diebold et al. reports that the reason of having
one of the developers as Scrum Master for two companies is because those companies report that they
believe developers has better insight into technicalities of the project [4]. Other examples of Scrum
Master tailoring choices include having multiple SMs and replacing SMs with other roles such as
developers or product owners [7][16].
4.3 RQ 1.3 Tailored Scrum Artifacts and Tailoring Styles
Fig. 8 shows the distribution of the papers report tailored Scrum Artifacts which are product backlog
and sprint backlog in various domains and companies.
Product Backlog
Sprint Backlog
0 2 4 6
Number of papers
Fig. 8 Type of Scrum Artifact Tailorings
All of the five studies that are given in Fig. 8 include Product Backlog tailoring whereas only two papers
refer to the Sprint Backlog tailoring choices [3][7]. In all of the studies that we analyzed, we only
observed Sprint and Product Backlog tailoring examples yet we did not encounter any other tailoring
choices such as burn down chart tailoring etc. In one of these papers, the entire team was not always
involved in creating the Sprint Backlog and it was being done by a single person which contradicts the
Scrum Guide definition. Additionally, product backlog items arrive from various sources such as
clients, end-users and the support team [3]. In another study, three of the interviewed teams do not have
a product backlog and 7 of the teams do not prioritize their product backlog items [13]. Other examples
of Sprint and product backlog tailoring choices include introducing both of the sprint and product
backlog and using additional artifacts which are not involved in Scrum [7], using detailed requirement
analysis documents instead of a product backlog which again contradicts the Scrum principles [14],
defining different concepts such as Feature Pool and Feature Tree to form a product backlog [17].
Distribution of the tailoring styles for Sprint and Product backlog can be stated as:
• Having multiple sprint backlogs
• Involving single person in creating the sprint backlog
• Having detailed requirement specification instead of product backlog.
• Not having a prioritized backlog.
• Having multiple product backlogs.
• Not having a product backlog.
• Having multiple backlog item sources.
4.4 RQ 2 Positive and Negative Evidences on the Consequences of Tailoring
Choices
The SLR data analysis shows that the aforementioned Scrum practice choices, lead to successful or
unsuccessful consequences. Although there is not enough evidence about specific Scrum practice
tailoring results, Fitzgerald et al. [12] stated that as the result of sprint planning and sprint tailoring
choices, such as introducing two planning sessions, keeping the planning simple by eliminating Gantt
charts and complex inter-dependencies between tasks, overall project success is increased. Eloranta et
al. [13] states that the tailoring choices made have resulted unsuccessful as there is no certain time limit
for a sprint, goals were not clear to the team and team members were not committed to the sprint goals
considering that the sprint could be extended at any time. Additionally, product backlog tailoring was
unsuccessful since the team ended up working on the wrong features that have no value to the customer.
Again, in the same study, as a result of not having estimations in a sprint, unrealistic sprint goals
demotivated the team members [13]. From the Sprint review tailoring point of view, as a result of not
having sprint review meetings for some of the teams, teams had to make changes at the late stages of
development since they do not receive feedback during sprint review meetings, they only had the chance
to get feedback when the customer starts using the product [12][13]. Finally, it is worth mentioning
about the results of Sprint retrospective tailoring results. Sprint retrospective tailoring choices such as
having too short retrospectives or not having retrospectives at all can be considered as an ad-hoc
development approach which ended up with teams not having a continuous improvement stage. In
another study, not having a fixed time for Daily Scrums and exceeding 15 minutes, led to fatigue among
team members and members lose their focus [15]. Additionally, most of the sprint planning tailoring
choices such as not having a sprint goal, not estimating the stories and including only sprint backlog as
the main feature source, led to unsuccessful results such as failure to implement important required
features, difficulties in defining sprint goals, and unplanned, unorganized sprint planning meetings. In
another study, it is stated that in sprint review meetings, external stakeholders were present and the
client was not present which led the developers not to understand client expectations [16]. Considering
the scrum role tailoring choices, it is stated that the development team had other responsibilities outside
of sprint scope which resulted in the distraction of the developers and eventually ended up with a delay
in delivery [16].
5. Discussion
The Sprint, Sprint Retrospective, Daily Scrum, Sprint Review, and Sprint Planning meeting are the
five Scrum practices that we found to be tailored in the studies. Sprint Review is the most frequently
tailored Scrum practice while Sprint itself is the least frequent one (see Fig. 2). Most frequently,
companies tailor these practices by either completely eliminating the practice or modifying the amount,
duration or participants of the practices. Most of the companies which does not include specific
practices in their context state that either they do not need to involve that practice or they are mature
enough to perform specific tasks without the need for particular Scrum practices.
Development team, Scrum Master, and Product Owner roles were tailored among various organizations
working on several domains. The most frequently tailored Scrum role was Product owner followed by
the development team and scrum master (see Fig. 6). In general, companies tailored Scrum roles by
modifying the number of people responsible for the role, assigning other responsibilities to the people
who are responsible for specific Scrum roles, having proxy roles on behalf of the original role, or not
including the specific role to their contexts.
Product backlog and sprint backlog are the two main artifacts that were tailored among various
companies. Product backlog tailoring was found to be more common compared to sprint backlog
tailoring (see Fig. 8). The most common way of artifact tailoring was found to be having multiple
backlogs, not having a backlog at all, using long documentation instead of backlogs, and not prioritizing
the backlog.
Some of the companies stated that tailoring Scrum components results in positive consequences by
showing that the efficiency of the team was increased [4][12]. However, we found out that most of the
companies indicated negative results from tailoring Scrum components. As a result of false tailoring
choices, most of the companies ended up with negative results such as not having a specific time limit
for a sprint, not having a clear sprint goal, working on wrong features that have no value to the customer,
not being able to get frequent feedback from the customer or setting unrealistic sprint goals. To some
point, tailoring the Scrum components can be beneficial if the companies pay attention to not violating
Scrum values and following the Scrum Guide in detail. Significant tailoring choices such as removing
a specific Scrum practice or role that is defined in the Scrum guide, ended up having negative
consequences for most of the teams.
5.1 Threats to Validity
As a result of the studies that we have included in this SLR, some validity concerns might
arise. These validity concerns can be listed as external and internal threats to validity.
5.1.1 Internal Validity
Internal validity in research refers to an experimental condition that makes a difference in the results,
such as asking diverse questions to participants and receiving answers in different granularity levels. In
this SLR, many studies that we analyzed used surveys or interviews as a research method to gather data
about Scrum tailoring from the participants. Various factors, such as being unable to develop a detailed
and precise question set, may have caused to receive answers which do not directly reflect the current
situation.
5.1.2 External Validity
Data collection methods in the studies that we included in this SLR do not represent the entire Agile
community. They are only limited to individuals who experienced Scrum tailoring in several projects.
Additionally, due to the criteria we already mentioned in the research methodology chapter, we included
23 papers in this SLR. As a result, our findings were limited, and we observed some Scrum tailoring
examples in a few studies, which might affect the generalizability of the results and can be considered
an external validity threat.
6. Conclusion
In this paper, we performed a systematic literature review to observe the Scrum component tailoring
choices such as practice, role, and artifact tailoring from various papers that include examples from
different organizations and their results.
We found that the most commonly tailored Scrum practice is sprint review followed by daily scrum,
the most commonly tailored Scrum role is Product Owner followed by the development team and Scrum
Master, and finally the most commonly tailored Scrum artifact is product backlog followed by sprint
backlog.
Additionally, in this study, we did not only present the tailored Scrum components but also how they
were tailored. Thus, we specifically investigated the most commonly tailored Scrum practices, roles,
and artifacts and how they were tailored among various projects.
Companies tailor their Scrum components based on various aspects such as domain limitations, lack of
resources, or business goals.
In this study, we also analyzed the papers that have information about the results of particular Scrum
practice tailoring choices, and we reported them as successful or unsuccessful based on the results from
the literature. Most of the tailoring styles from various organizations ended up being unsuccessful which
is validated through interviews or case studies that have been done by the previous literature. The reason
for performing unsuccessful Scrum tailoring choices for these companies is mostly because of violating
Scrum rules and values that are defined in the Agile Manifesto.
This study is actually an indication of AD-hoc development rather than Scrum development. Prior to
our literature analysis, our assumptions were mostly about finding small deviations of the Scrum
components from their original definitions. However, most of the application choices of Scrum method
were found to be kind of ad-hoc style of the Scrum which has a major difference and approach that
contradicts with the agile principles and values defined in the Agile Manifesto.
Indeed, most companies have valid reasons to adjust the original definition of the Scrum practices, roles
and artifacts. Thus, tailoring some of the Scrum components can be a must for most companies.
However, while tailoring particular practices, roles, or artifacts, companies and individuals who make
the decisions for Scrum rules, need to preserve the values of Scrum. To have a more detailed
understanding of the general approach in the industry, it is necessary to make more extended research
on specific Scrum component tailoring choices through case studies and interviews, and results of these
tailoring choices should be presented with specific examples.
Future studies can extend this study by working on other Agile software development
methodologies such as XP, Kanban, Lean, etc., to have more comprehensive information in the
field. Additionally, results from this SLR can be combined with other research methods such
as surveys, interviews, and case studies. Additionally, observing how Scrum components are
being tailored widely in the industry can be a future research area.
7. References
[1] Ciric, D., Lalic, B., Gracanin, D., Tasic, N., Delic, M., & Medic, N. (2019). Agile vs. traditional
approach in project management: Strategies, challenges and reasons to introduce agile. Procedia
Manufacturing, 39, 1407–1414. https://doi.org/10.1016/j.promfg.2020.01.314
[2] Manifesto for Agile Software Development. (n.d.). Retrieved April 19, 2022, from
https://agilemanifesto.org/
[3] Masood, Z., Hoda, R., & Blincoe, K. (2020). Real world scrum a grounded theory of variations
in practice. IEEE Transactions on Software Engineering, 1–1.
https://doi.org/10.1109/tse.2020.3025317
[4] Diebold, P., Ostberg, J.-P., Wagner, S., & Zendler, U. (2015). What do practitioners vary in using
scrum? Lecture Notes in Business Information Processing, 40–51. https://doi.org/10.1007/978-
3-319-18612-2_4
[5] Kalus, G., & Kuhrmann, M. (2013). Criteria for software process tailoring: A systematic review.
Proceedings of the 2013 International Conference on Software and System Process – ICSSP
2013.
[6] The scrum guide. Scrum.org. (2020). Retrieved April 19, 2022, from
https://www.scrum.org/resources/scrum-guide
[7] Hron, M., & Obwegeser, N. (2018). Scrum in practice: An overview of Scrum adaptations.
Proceedings of the 51st Hawaii International Conference on System Sciences.
[8] Campanelli, A. S., & Parreiras, F. S. (2015). Agile methods tailoring – A systematic literature
review. Journal of Systems and Software, 110, 85–100 https://doi.org/10.1016/j.jss.2015.08.035
[9] Diebold, P., & Dahlem, M. (2014). Agile practices in practice: a mapping study. Proceedings of
the 18th International Conference on Evaluation and Assessment in Software Engineering -
EASE '14. https://doi.org/10.1145/2601248.2601254
[10] Jovanovic, M., Mesquida, A.-L., Mas, A., & Colomo-Palacios, R. (2020). Agile transition and
adoption frameworks, issues and factors: A systematic mapping. IEEE Access, 8, 15711–15735.
[11] B.Kitchenham, O.Pearl Brereton, D.Budgen, M.Turner, J.Bailey, S.Linkman, Systematic
literature reviews in software engineering- a systematic literatüre review. Inf. Softw. Technol.
51(1),7-15(2009)
[12] Fitzgerald, B., Hartnett, G., & Conboy, K. (2006). Customising agile methods to software
practices at Intel Shannon. European Journal of Information Systems, 15(2), 200–213.
https://doi.org/10.1057/palgrave.ejis.3000605
[13] Eloranta, V.-P., Koskimies, K., & Mikkonen, T. (2016). Exploring scrumbut—an empirical study
of scrum anti-patterns. Information and Software Technology, 74, 194–203.
https://doi.org/10.1016/j.infsof.2015.12.003
[14] Hossain, E., Bannerman, P. L., & Jeffery, R. (2011). Towards an understanding of tailoring
scrum in Global Software Development. Proceeding of the 2nd Workshop on Software
Engineering for Sensor Network Applications - SESENA '11.
https://doi.org/10.1145/1987875.1987894
[15] Mortada, M., Ayas, H. M., & Hebig, R. (2020). Why do software teams deviate from scrum?
Proceedings of the International Conference on Software and System Processes.
https://doi.org/10.1145/3379177.3388899
[16] Hassani-Alaoui, S., Cameron, A.-F., & Giannelia, T. (2020). “we use scrum, but …”: Agile
Modifications and project success. Proceedings of the Annual Hawaii International Conference
on System Sciences.
[17] Pérez, J., Díaz, J., Garbajosa, J., & Yagüe, A. (2014). Bridging user stories and software
architecture. Agile Software Architecture, 215–241. https://doi.org/10.1016/b978-0-12-407772-
0.00008-3
[18] Salameh, A., & Bass, J. M. (2020). Heterogeneous tailoring approach using the Spotify model.
Proceedings of the Evaluation and Assessment in Software Engineering.
https://doi.org/10.1145/3383219.3383251
[19] Nikitina, N., Kajko-Mattsson, M., & Strale, M. (2012). From scrum to scrumban: A case study
of a process transition. 2012 International Conference on Software and System Process (ICSSP).
https://doi.org/10.1109/icssp.2012.6225959
[20] Robinson, P. T., & Beecham, S. (2019). Twins - this workflow is not scrum: Agile process
adaptation for Open Source Software Projects. 2019 IEEE/ACM International Conference on
Software and System Processes (ICSSP).
[21] Akbar, R. (2019). Tailoring agile-based software development processes. IEEE Access, 7,
139852–139869. https://doi.org/10.1109/access.2019.2944122
[22] Tripp, J. F., & Armstrong, D. J. (2014). Exploring the relationship between organizational
adoption motives and the tailoring of Agile Methods. 2014 47th Hawaii International Conference
on System Sciences. https://doi.org/10.1109/hicss.2014.589
[23] F. Tripp, J., & Armstrong, D. J. (2016). Agile methodologies: Organizational adoption motives,
tailoring, and performance. Journal of Computer Information Systems, 58(2), 170–179.
[24] Kiv, S., Heng, S., Kolp, M., & Wautelet, Y. (2017). An intentional perspective on partial agile
adoption. Proceedings of the 12th International Conference on Software Technologies.
[25] Bass, J. M. (2016). Artefacts and agile method tailoring in large-scale offshore software
development programmes. Information and Software Technology, 75, 1–16.
https://doi.org/10.1016/j.infsof.2016.03.001
[26] Campanelli, A. S., Camilo, R. D., & Parreiras, F. S. (2018). The impact of tailoring criteria on
Agile Practices Adoption: A survey with novice agile practitioners in Brazil. Journal of Systems and
Software, 137, 366–379.
[27] Hoda, R., Noble, J., & Marshall, S. (2011). Developing a grounded theory to explain the practices
of self-organizing agile teams. Empirical Software Engineering, 17(6), 609–639.
https://doi.org/10.1007/s10664-011-9161-0