On the Adaptations of the Scrum Framework Software Development

Events: Literature and Practitioners Analysis using Feature Models

Luciano A. Garcia

1 a

, Edson OliveiraJr

1 b

, Gislaine C. L. Leal

1 c

and Marcelo Morandini

2 d

Informatics Department, State University of Maring

a (UEM), Maring

a, Brazil

School of Arts, Sciences and Humanities, University of S

ao Paulo (USP), S

ao Paulo, Brazil

Keywords:

Adaptation, Feature Model, Events, Scrum.

Abstract:

Scrum is one of the most well-known and used agile methods for software development. Practitioners highlight

the Sprint event as the heart of Scrum. Different kinds of Scrum events aid at performing Sprints. We gathered

evidence of industrial adaptations of Scrum events based on the existing reporting literature and a survey

with practitioners. We grouped, represented and uniﬁed these adaptations in terms of feature models. Such

representation aids to register practitioners’ knowledge, thus creating an structure capable of instantiating it to

new software development solutions deployment.

1 INTRODUCTION

Agile methods have become increasingly popular in

software development. Scrum is one of the most

adopted in industry Sharma and Hasteer (2016). In

a survey conducted by Alliance (2017), 94% of re-

spondents use SCRUM.

The Scrum structure is formed by the follow-

ing main components: roles, events, artifacts, and

rules. In this paper we will focus on the events that

take place in the operation of Scrum. According to

Schwaber and Sutherland (2017), the Scrum events

create regularity and minimizing the need for meet-

ings. Among these events, the Sprint is considered

the most important one, being called the “heart of

Scrum”, playing the role of a container for the other

events necessary for the conduction of the Scrum

Schwaber and Sutherland (2017).

We have observed there are few studies specif-

ically dedicated to reporting the adaptations of the

Scrum events, as we understand different software de-

velopment projects have particularities. Such events

are essential to establish the quality and assertive-

ness of the development time of the software incre-

ments generated in the process of conducting Scrum.

For this, we performed a Systematic Mapping Study

https://orcid.org/0000-0001-7163-6987

https://orcid.org/0000-0002-4760-1626

https://orcid.org/0000-0001-8599-0776

https://orcid.org/0000-0001-5402-9544

(SMS) of the literature on industry reported adapta-

tions of the Scrum events. As a complementary strat-

egy, we also carried out a survey with Scrum practi-

tioners to conﬁrm the SMS results.

The adaptations involved in the components of

Scrum, including events, are possible as the Scrum

is a ﬂexible framework Schwaber and Sutherland

(2017). In provides several different features, for ex-

ample an event might have different time frames for

similar projects. According to Krzysztof and Eise-

necker (2000), a feature is a property of the system

that is relevant to some stakeholders and is used to

capture common points or discriminate between sys-

tems in a framework (family). Assuming that Scrum

can be understand as a family with possible distin-

guish project feature instances (systems), we can use

feature models to represent such abstraction. There-

fore, similar and variable Scrum events aspects can be

represented in such models Krzysztof and Eisenecker

(2000).

Being aware of which features can be selected and

respective choices makes Scrum deployment more

manageable. To do so, we gathered, analyzed and

elaborated feature models for Scrum events from the

SMS and the survey. Once we produced feature mod-

els for the SMS and the survey, we conducted a pro-

cess of uniﬁcation of such models making them com-

pliant with the Scrum guide Schwaber and Sutherland

(2017). In addition, we presented an example of in-

stantiation of such feature models.

416

Garcia, L., OliveiraJr, E., Leal, G. and Morandini, M.

On the Adaptations of the Scrum Framework Software Development Events: Literature and Practitioners Analysis using Feature Models.

DOI: 10.5220/0009578904160423

In Proceedings of the 22nd International Conference on Enterprise Information Systems (ICEIS 2020) - Volume 2, pages 416-423

ISBN: 978-989-758-423-7

2 BACKGROUND AND RELATED

WORK

2.1 The Scrum Framework Events

To be able to identify how adaptations in Scrum

events take place we followed the Scrum guides 2017

Schwaber and Sutherland (2017) and 2010 Schwaber

and Sutherland (2010).

The main Scrum event is the Sprint. Sprints are

interactions in which the product (software) is devel-

oped. At the end of each Sprint a functional version of

the product must be released. The other Scrum events

are deﬁned according to the Sprint and are detailed as

follows.

Release Planning. This event is no longer compul-

sory since 2011. In general, the objective of this ar-

tifact is to plan how the increments produced in each

Sprint will be integrated and delivered in functional

and valuable versions for investors. Scrum does not

mention a speciﬁc time-boxed for this event.

Sprint Planning. It is a meeting, in which people

plan the work to be done in a Sprint. This event tries

to answering the following questions: What is the

purpose of the Sprint?; What should be delivered as a

result of increasing a Sprint?; and How will the work

be done to deliver the increment?

Daily Scrum. It is a meeting that takes place ev-

ery day for the duration of the Sprint. Three ques-

tions must be answered by all members of the Dev.

Team: What was done yesterday to achieve the

Sprint goal?; What will be done today to achieve

the Sprint goal?; and Have obstacles been found

that can interfere with the progress of the Sprint?

Sprint Review. The focus of this meeting is on what

was produced in a Sprint.

Sprint Retrospective. This event occurs after the

Sprint Review and before the next Sprint Planning.

It is an opportunity for the Scrum roles to reﬂect on

relationships, processes and tools used and to create

an improvement plan to be applied in the next Sprint.

2.2 Feature Modeling

According to Czarnecki et al. (2005) feature is a

system property relevant to some stakeholders (cus-

tomers, analysts, architects, developers, system ad-

ministrators, etc.) and is used to capture similarities

or differences between systems in a family. Figure 1

shows an example of a feature model.

A feature model is composed of basic elements,

namely (Mendonc¸a, 2009): feature diagram, compo-

Modeled with FeatureIDE - http://www.featureide.com

Figure 1: Example of a Feature Model (Kang et al., 1990).

sition rules, and relational analysis. In Figure 1, fea-

tures are represented by the tree nodes described in

the feature diagram, and in this hierarchy the child

features can be classiﬁed as Takeyama and Chiba

(2013): Mandatory - feature must be selected; Op-

tional - feature may be selected; Or - at least one fea-

ture must be selected; Alternative - only one feature

should be selected; and Abstract - does not impact in

the implementation of a system.

Composition Rules deﬁne the relationship be-

tween features that cannot be expressed in feature di-

agrams (Lobo and Rubira, 2009). In Figure 1, there is

a composition rule which requires the car to have an

Engine with Horsepower greater than 100 to support

the air conditioning.

2.3 Related Work

In the work of Ashraf and Aftab (2017), a System-

atic Literature Review (SLR) was carried out. While

in this paper we are concerned with highlighting the

adaptations practiced in Scrum events, the work of

Ashraf and Aftab (2017) was concerned with the

Scrum process and its variations due to the area in

which it was used. Despite the Ashraf and Aftab

(2017) work providing one research questions for

events, it only sought to reﬂect on new practices for

the events, with no worrying about compliance with

the recommendations of the Scrum guide. Another

difference is we conﬁrm the SMS ﬁndings with a sur-

vey with practitioners, whereas the study of Ashraf

and Aftab (2017) relies only in the secondary study

ﬁndings.

With respect to the work of Diebold et al. (2015),

there are similarities in relation to the direct search

for the practitioners’ experience. For this paper we

used the survey investigation method, while Diebold

et al. (2015) used structured interviews. As in our

study, Diebold et al. (2015) also gave importance to

compliance with the recommendations of the Scrum

guide, regarding the adaptations of its components.

Although Diebold et al. (2015)’s work is not exclu-

sively about Scrum events, it brings relevant informa-

On the Adaptations of the Scrum Framework Software Development Events: Literature and Practitioners Analysis using Feature Models

417

tion about them. Another aspect of similarity was the

comparison of the practitioners’ experiences with that

found in the literature. The main difference is in the

type of study and in the selection of participants. We

sought an international approach in the survey, while

in the interviews conducted in Diebold et al. (2015)

portrayed the practices in the German industry.

3 ADAPTATIONS FOR SCRUM

EVENTS

The adaptations reported for Scrum events in this

work are a cut to systematic mapping of the literature

and a survey conducted with Scrum practitioners. In

the next sections we present the two studies that were

carried out. The presentation will be made in a sum-

marized form, for a space limit issue focusing on the

adaptations in the Scrum events.

3.1 Adaptations from the Literature

We performed an SMS

to ﬁnd reported adaptations

of the Scrum events following recommendations of

Petersen et al. (2015) and Kitchenham et al. (2015).

We searched studies in ﬁve electronic databases.

We also manually searched studies in 11 journals and

17 conferences of Software Engineering. We came

up with 281 primary studies. By applying inclu-

sion/exclusion criteria we reduced such list to 50. We

used the StArt

tool to aid us at organizing retrieved

studies. The list of resultant studies is available at

https://zenodo.org/record/3357804.

3.1.1 Findings for Literature Scrum Events

We wanted to answer the following research ques-

tion with the SMS: RQ: Which Scrum events have

been adapted? This question was supported by the

following extraction information: Do events follow

the Scrum guide recommendations? and What is the

time-frame for each event?

Table 1 shows the studies with adaptations to

Scrum events. Out from 50 selected studies, 31 pre-

sented adaptations in the events.

Rows in table showing more than one study were

grouped by the study that affected the greatest number

of events among them (Total). We can identify the

event with most adaptations is Sprint (28/31), and the

one with less adaptations is Release Planning (1/31).

Table 2 lists extracted information related to com-

pliance with the Scrum guide recommendations.

Currentlyunderreviewinajournal.

http://lapes.dc.ufscar.br/tools/start\ tool

We can observe in Table 2 none of the studies fully

comply with the Scrum recommendations (“Yes” col-

umn). 20 out of 31 studies partially comply with the

recommendations (“Partial” column) and 11 out of 31

do not comply with Scrum recommendations. Partial

means one study mentions more than one event and

at least one of them complied with the Scrum recom-

mendations.

Sprint.

With regard to Sprint, we found most studies pointed

a time-box between one and four weeks. Of the

20 selected studies, one did not inform the time-box

adopted. Another study reported an 8-week time-

boxed Sprint. In addition, one study reported a 2.5-

week time-boxed for Sprint. Half of the studies

(10/20) reported Sprint with a 2-week time-boxed.

Daily Scrum.

As for Daily Scrum in addition to time-boxed, we an-

alyzed the frequency in which the meeting was held

and the form of presence in it.

Regarding time-boxed, he observed the following

time intervals: 5 minutes, 15 minutes, between 15 to

20 minutes and between 15 to 35 minutes. Regard-

ing the frequency in which the Daily Scrum was per-

formed, the studies mentioned the following: daily,

twice a week, 3 times a week and many times a day.

For the type of presence of participants in the meet-

ing, the following was found: physical presence, and

virtual presence. Being that in the virtual presence the

following means were pointed out: Google groups,

Google Docs, email, chats.

Sprint Review.

Regarding the time-boxed of the Sprint Review event,

only two studies (2/20) mentioned the time boxed

used and were: 5 minutes and 8 hours.

Sprint Retrospective.

As for the Sprint Retrospective, only three studies re-

ported the time allotted for this event, which were

as follows: 5 minutes, 15 minutes, 30 minutes and

1 hour.

Sprint Planning.

Only four studies reported times for the Sprint Plan-

ning event. In the studies, time-boxed of 2, 3, 16

hours and 1 week were mentioned.

Release Planning.

Regarding Release Planning, only one study reported

such an event and adopted a 1-week time-boxed.

3.1.2 Feature Modeling of Literature Events

Adaptations

With the information found in the SMS for the adapta-

tion of Scrum events, a feature model was elaborated

for them.

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

418

Table 1: Scrum events with adaptations.

Study ID Sprint Daily Scrum Review Retrospective Planning Release

S3, S8, S9, S28, S52, S58 X

S4 X X X X

S5, S6, S26, S31, S38 X X X X X X

S11 X X X

S12, S13, S17, S22, S29,

S36, S37, S41, S43, S49

X X

S14 X X X X X

S15 X X X X

S20 X

S30 X X

S33 X

S44 X

S48 X X X X

S53 X X X

Total 28 17 07 08 07 01

Table 2: Compliance of event adaptations with Scrum

guide.

Study ID Count Yes Partial No

None 00 X

S4, S5, S6,

S8, S9, S11,

S12, S13, S14,

S15, S22, S28,

S29, S30, S37,

S41, S48, S49,

S53, S58

20 X

S3, S17, S20,

S26, S31, S33,

S36, S38, S43,

S44, S52

11 X

Total 31 00 20 11

Due to the limited space and to favor the reading of

the feature models, we will use a notation for features

and a short description for the event names.

Notation for Features.

The identiﬁer for each feature will be composed as

follows: F99xxM, where the letter F to represent the

word Feature, 99 represents a sequential for feature,

xx is an abbreviation for the event name, and the letter

M identiﬁes it as an SMS source feature.

Short Names for Events.

In the notation for identifying the features, the let-

ters xx will be replaced with the letters correspond-

ing to each event as follows: rp - Release Planning; st

- Sprint; ds - Daily Scrum; sw - Sprint Review; sr -

Sprint Retrospective; and sp - Sprint Planning.

The short names presented for the events will be

used to identify the events in the feature model at the

top level, only they will be written in capital letters.

Table 3 shows the adaptations found in the SLM

and described as features. Table 3 serves as support

for the elaboration of the feature model for events

based on SMS.

Figure 2 shows the feature model that originated

from the data in Table 3.

Table 3: Features of each Scrum event in SMS.

ID Feature Description ID Feature Description

F01rpM 1 week F15dsM many times a day

F02stM 1 week F16dsM physical

F03stM 2 weeks F17dsM

Virtual

(email, chat)

F04stM 2.5 weeks F18dsM

Virtual

(Google Groups,

Google Docs)

F05stM 3 weeks F19swM 5 minutes

F06stM 4 weeks F20swM 8 hours

F07stM 8 weeks F21srM 5 minutes

F08dsM 5 minutes F22srM 15 minutes

F09dsM 15 minutes F23srM 30 minutes

F10dsM 15 to 20 minutes F24srM 1 hour

F11dsM 15 to 35 minutes F25spM 2 hours

F12dsM daily F26spM 3 hours

F13dsM twice a week F27spM 16 hours

F14dsM 3 times a week F28spM 1 week

3.2 Adaptations from the Practitioners

Survey

To capture the experience of practitioners regarding

the use of Scrum, a survey was conducted. This sur-

vey was carried out according to Forza (2002), ob-

serving the following steps: Planning, Pilot Test, Data

Collection and Analysis of Results.

The research was carried out with specialists from

Brazil and abroad who work in software development

and make use of the Scrum framework in this envi-

ronment. The total respondents of the survey were

14 practitioners. It was observed that these 14 prac-

titioners answered all questions adequately with the

respective statements, with no inconsistent data.

Regarding the experience of respondents in using

Scrum 85.7% answered that they have used Scrum for

more than a year. Of this total, 35.7% use between 1

and 3 years, 21.4% use Scrum between 4 and 6 years

and 28.6% use Scrum for more than six years.

Below, we detail the main ﬁndings about practi-

tioners’ responses.

On the Adaptations of the Scrum Framework Software Development Events: Literature and Practitioners Analysis using Feature Models

419

Figure 2: Feature model of SMS Scrum Events Adaptations.

3.2.1 Findings for Survey Scrum Events

The information obtained from the Survey for the

events was gathered and classiﬁed. It does not matter

at that moment whether or not they are in compliance

with the recommendations of the Scrum guide.

For the sake of space limitations, we will not detail

the percentages of responses. Since for us it is enough

that an adaptation has been cited by a respondent for

it to be considered in the elaboration of the models.

In the sequence, information acquired for each

event will be described individually.

Release Planning.

This event became optional after the 2010 version

of Scrum Schwaber and Sutherland (2010), but was

found in the Survey responses,when asked: How long

did this event last? In the responses, the time of 1 day

was unanimously pointed out.

Sprint Planning.

For this event, two questions were asked, namely:

How long did Sprint Planning last? and When is the

best time to carry out Sprint Planning?

Regarding the duration of the event, the follow-

ing were identiﬁed: following alternatives: 2 hours or

less, 3 hours, between 4 and 5 hours. For the moment

when Sprint Planning was carried out, the answers

were concentrated on: at the beginning of Sprint and

before starting Sprint.

Sprint.

For Sprint the following questions were asked: How

long does the Sprint last? What is the best day of the

week to start Sprint? When is the best time to hold

the Planning, Review and Retrospective? When is the

best time to perform software tests? What technique

was used to estimate Sprint time?

For the duration of Sprint were reported: 1 week,

2 weeks and 4 weeks. Regarding the best day of the

week to start Sprint, the following were pointed out:

Monday, Tuesday, Wednesday and Thursday. For the

time to hold the Planning events, Review and Retro-

spective, got the following answers: on separate days,

on the same day, Review and Retrospective on the

same day and planning on another day. Regarding

the timing of the tests: in the sprint itself, in the next

sprint. Regarding the technique used to estimate the

sprint time, the following responses were mentioned:

Planning Poker, Task estimation and Planning Poker

translated into hours.

Daily Scrum.

The Daily Meeting presented the duration of 15 min-

utes, informed by the respondents and there was no

mention of other times. As for the frequency in which

the daily meeting took place, it was mentioned by

most respondents that it was held daily. As for pres-

ence, mention was made in addition to physical pres-

ence, virtual presence, which had the following forms

mentioned: Skype for Business, Microsoft Teams,

Skype, Zoom meeting.

Sprint Review.

For this event two questions were asked: How long

does the Sprint Review last? When was the Sprint

Review performed?

For the duration of this event, the following re-

sponses were obtained: less than 1 hour, 1 hour, 2

hours and 3 hours. Regarding the moment when the

Sprint Review was carried out, the answers were men-

tioned: carried out on the last day of the Sprint, car-

ried out after the end of the Sprint and carried out be-

fore the last day of the Sprint.

Sprint Retrospective.

For the Sprint Retrospective the following questions

were asked: How long does the Sprint Retrospective

last? How were the improvements identiﬁed in the

Sprint Retrospective handled? What technique was

used to conduct the Sprint Retrospective meeting?

Regarding the duration of this event, the respon-

dents indicated: 45 minutes or less, 1 hour, 2 hours.

For the improvements identiﬁed in this event, the re-

spondents informed that they were treated as follows:

they were inserted as items of the PB to be imple-

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

420

mented in the next Sprints and were implemented in

the next Sprint. Regarding the way the meeting of

this event was conducted, the respondents reported

the following: (i) any dynamics that added value, (ii)

3 questions, what was good, what can improve, ac-

tion items, (iv) Useful / Viable - points to improve or

maintain, (v) Balloon Technique: Stop, Continue and

Start, (vi) 4L, Sail boat, speedcar, (vii) W3 or Sad /

Mad / Glad.

3.2.2 Feature Modeling of Survey Events

Adaptations

With the information found with a survey for the

adaptations of Scrum events, a model feature was

elaborated for them. It used the same notation deﬁned

in Section 3.1.2, with a small change in the feature

identiﬁer. Instead of the feature ID ending with the

letter M, it will end with the letter S to indicate that

the origin of the feature is from the survey.

Table 4 shows the features and their descriptions.

Based on the information in Table 4, the feature

model was elaborated, which is shown in Figure 3.

4 FEATURE UNIFICATION

PROCESS

The feature models generated for SMS and Survey

represent the realities found in these studies. Thus,

the representation of the feature include features that

are not in accordance with the recommendations of

the SCRUM guide. Also, as they were conducted

independently, to conﬁrm the information, some fea-

tures may be in both models and for consolidation be-

tween them, they need to be uniﬁed.

Based on Tables 3 and 4 we prepared a uniﬁed model

for Scrum events with adaptations found in the SMS

and the Survey (see Figures 4 and 5).

4.1 Scrum Guide Compliance Check

The inconsistencies in the adaptations of Scrum

events were addressed individually for each event. We

have identiﬁed features that do not conform to the

Scrum Guide for the SMS and the Survey.

Release Planning - RP.

The feature found for this event, both SMS and the

Survey, was that of time. As mentioned earlier, this

event is no longer formally part of the Scrum guide

since 2010. However, there were time notes for this

event and for 1 week and 1 day respectively for the

SMS and the Survey. As the Scrum guide does not

mention time, the features F01rpM and F01rpS will

be part of the uniﬁed model for the events.

Sprint - ST.

Regarding the time, only one feature was eliminated

due to inconsistency, which is F07stM of the SMS, as

Scrum stipulates as a time of deduction for String no

more than 30 days.

The other features do not represent inconsisten-

cies with the Scrum guide or are not mentioned as

problems.

Daily Scrum - DS.

Regarding the Daily Scrum time, the following fea-

tures of the SMS were chosen: F10dsM and F11dsM.

They were eliminated because they exceeded the time

allocated for this event by Scrum, which is a maxi-

mum of 15 minutes. For the Survey, as for time, there

was no inconsistent feature and relation to the Scrum

guide.

Regarding the Daily Scrum’s frequency, the fol-

lowing featues of SMS are at odds with the Scrum

guide: F13dsM, F14dsM, F15dsM. Because Scrum

mentions that this event must be daily and one on the

day, in the same place and time.

Sprint Review - SW.

As for the duration of this event, only the F20swM

feature will be eliminated. Because Scrum mentions

that for a 30-day Sprint the duration of this event must

be 4 hours.

Regarding when to start this event the F29swS and

F30swS will be eliminated, as the Scrum guide de-

ﬁnes that it must be carried out at the end of the Sprint.

Sprint Retrospective - SR.

No features were found that do not comply with the

recommendations in the Scrum guide.

Sprint Planning - SP.

Regarding the duration of this event, two features

were eliminated: F27spM and F28spM, as they are

outside the time-boxed deﬁned by the Scrum guide

for this event, which is a maximum of 8 hours for a

30-day Sprint.

With when this event should start, the Scrum

guide does not make it clear, so we assume that the

two features found for the Survey are correct.

4.2 Elimination of Redundant Features

After deﬁning the feature models according to the rec-

ommendations of the Scrum guide, the features that

were present in both Survey and SMS models were

eliminated. In these cases, we gave preference to the

Survey feature to compose the uniﬁed model.

To eliminate the redundancies of the features in

the SMS and Survey models, we analyze each event

individually.

On the Adaptations of the Scrum Framework Software Development Events: Literature and Practitioners Analysis using Feature Models

421

Table 4: Features of Scrum event in Survey.

ID Feature Description ID Feature Description ID Feature Description

F01rpS 1 day F17dsS 15 minutes F32srS 1 hour

F02stS 1 week F18dsS daily F33srS 2 hours

F03stS 2 weeks F19dsS Presence: physics F34srS

Improvement: insert items

in the PB to do in the next sprint

F04stS 4 weeks F20dsS Presence: virtual: Skype for Business F35srS Improvement: do in the next sprint

F05stS Start : Monday F21dsS Presence: virtual: Microsoft Teams F36srS Manage: any dynamics that added value

F06stS Start : Tuesday F22dsS Presence: virtual: Skype F37srS

Manage: 3 questions,

What was good? What can improve?

action items

F07stS Start: Wednesday F23dsS Presence: virtual: Zoom meeting F38srS

Manage: Useful / Viable - points

to improve or maintain

F08stS Start: Thursday F24swS less than 1 hour F39srS

Manage: Balloon Technique:

Stop, Continue and Start

F09stS Do sp sw sr: on separate days F25swS 1 hour F40srS Manage: 4L, Sail boat, speedcar

F10stS Do sp sw sr: on the same day F26swS 2 hours F41srS Manage: W3 or Sad / Mad / Glad

F11stS

Do sp sw sr: Review and

Retrospective on the same day

and planning on another day

F27swS 3 hours F42spS 2 hours or less

F12stS Tests: in the sprint itself F28swS Start: on the last day of the Sprint F43spS 3 hours

F13stS Tests: in the next sprint F29swS Start: after the end of the Sprint F44spS 3 at 5 hours

F14stS Tec Estimate: Planning Poker F30swS Start: before the last day of the Sprint F45spS Start: sprint start

F15stS Tec Estimate: Task estimation F31srS 45 minutes or less F46spS Start: before starting the sprint

F16stS

Tec Estimate: Planning Poker

translated into hours

Figure 3: Feature model of Survey Scrum Events Adaptations.

Figure 4: Feature model of Uniﬁed Scrum Event Adapta-

tions - Part 1.

Release Planning - RP. No feature redundancies

were found for this event. Therefore, the features

found were part of the uniﬁed model for the event.

Sprint - ST. For Sprint, with regard to the duration

feature, the same features were found in the SMS as in

Figure 5: Feature model of Uniﬁed Scrum Event Adapta-

tions - Part 2.

the Survey. We then eliminated the features of SMS in

the composition of the uniﬁed model of events, which

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

422

are: F02stM, F03stM, F06stM. We included the fea-

tures: F04stM and F05stM, in the uniﬁed model for

the events, as they are different from all the features

found for the Survey. The other features for this event

are already represented by the features found in the

Survey and which have already gone through the veri-

ﬁcation process for compliance with the Scrum guide.

Daily Scrum - DS. Regarding time, the F09dsM and

F17dsS features are the same and we opted for the

Survey feature to compose the uniﬁed model for the

event. As for the frequency of this event, the F12dsM

feature is the same as the F18dsS feature, we chose to

integrate the Survey feature into the model. As for the

form of presence for this event the features F16dsM

and F19dsS are the same, we chose to compose the

uniﬁed model of events the feature F19dsS.The SMS

F17dsM and F18dsM features will be incorporated

into the uniﬁed model for the events, as they do not

have correspondents in the Survey.

Sprint Review - SW. As for the duration of these

events, we have incorporated the F19swM feature to-

gether with the others in the Survey to the uniﬁed

model for the event, as they are not the same and met

the recommendations of the Scrum guide.

Sprint Retrospective - SR. As for the duration of

these events, only the F24srM and F32srS features

are the same, we chose to keep the Survey’s source

feature. The others with respect to time will be in-

corporated into the model because they have no cor-

respondents between them.

Sprint Planning - SP. Regarding the duration of this

event, the features of the SMS and the Survey are the

same: F26spM and F43spS, we chose to keep only

that of the Survey in the uniﬁed model. The F42spS

feature includes the F25spM feature, so we will in-

corporate the F42spS feature in the uniﬁed model.

5 CONCLUSIONS

We observed there is little information available on

handling Scrum events. The literature most often re-

ports the features of the duration of events, but Scrum

has many other details of equal importance for the

events. In the Survey conducted, we asked ques-

tions to understand the aspects not found in the lit-

erature and are part of the Scrum guide. Even in the

Survey, few responses were not in accordance with

the Scrum recommendations. We understand this is

due to the fact participants had a good experience in

Scrum practices. We then developed a uniﬁed model

of adaptations. The feature model is especially useful

for grouping and classifying the information obtained,

giving visibility to the knowledge reported in the lit-

erature and with practitioners. The feature model al-

lows to instantiate new versions of Scrum, within the

guidelines’ recommendations, for application in soft-

ware development projects.

As future work we will validate the resulting

model based on an empirical study. Another oppor-

tunity for future is the statement of guidelines to cre-

ate a version of Scrum more suitable for the software

development companies, based on feature models.

REFERENCES

Alliance, S. (2017). State of scrum 2017-2018. scaling and

agile transformation.

Ashraf, S. and Aftab, S. (2017). Latest transformations in

scrum: a state of the art review. International Journal

of Modern Education and Computer Science, 9(7):12.

Czarnecki, K., Helsen, S., and Eisenecker, U. (2005). For-

malizing cardinality-based feature models and their

specialization. Software process: Improvement and

practice, 10(1):7–29.

Diebold, P., Ostberg, J.-P., Wagner, S., and Zendler, U.

(2015). What do practitioners vary in using scrum?

In XP, pages 40–51. Springer.

Forza, C. (2002). Survey research in operations man-

agement: a process-based perspective. Interna-

tional journal of operations & production manage-

ment, 22(2):152–194.

Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E.,

and Peterson, A. S. (1990). Feature-oriented domain

analysis (foda) feasibility study. Technical report,

Carnegie-Mellon Univ Pittsburgh Pa Software Engi-

neering Inst.

Kitchenham, B. A., Budgen, D., and Brereton, P. (2015).

Evidence-Based Software Engineering and Systematic

Reviews. Chapman & Hall/CRC.

Krzysztof, C. and Eisenecker, U. W. (2000). Genera-

tive Programming: Methods, Tools and Applications.

Addison-Wesley.

Lobo, A. E. d. C. and Rubira, C. M. F. (2009). A study

for deployment of component-based software product

line. Campinas-SP, Campinas State University.

Mendonc¸a, M. (2009). Efﬁcient reasoning techniques for

large scale feature models. PhD thesis, University of

Waterloo.

Petersen, K., Vakkalanka, S., and Kuzniarz, L. (2015).

Guidelines for conducting systematic mapping stud-

ies in software engineering: An update. Information

and Software Technology, 64:1–18.

Schwaber, K. and Sutherland, J. (2010). The Deﬁnitive

Guide to SCRUM: The rules of the Game. Scrum.org.

Schwaber, K. and Sutherland, J. (2017). The Deﬁnitive

Guide to SCRUM: The rules of the Game. Scrum.org.

Sharma, S. and Hasteer, N. (2016). A comprehensive study

on state of scrum development. In ICCCA, pages 867–

872.

Takeyama, F. and Chiba, S. (2013). Implementing fea-

ture interactions with generic feature modules. In SC,

pages 81–96.

On the Adaptations of the Scrum Framework Software Development Events: Literature and Practitioners Analysis using Feature Models

423