Orchestrating Functional Change Decisions in Scrum Process using

COSMIC FSM Method

Asma Sellami

, Mariem Haoues

, Nour Borchani

and Nadia Bouassida

Mir@cl Laboratory, University of Sfax, ISIMS, BP 242. 3021, Sfax, Tunisia

Mir@cl Laboratory, University of Sfax, FSEGS, BP 1088. 3018, Sfax, Tunisia

Keywords:

Functional Change, User Requirements, COSMIC ISO 19761, Functional Size Measurement, Scrum, User

Story Description.

Abstract:

Because user requirements change frequently during the software life-cycle, project managers looked at ﬂex-

ible methods that manage changes as more information take place. Today, agile methods such as Scrum are

increasingly used in software organizations to avoid the danger of “scope creep” and project delays. Although

the scrum method is gaining popularity, a change request is still poorly evaluated within an ongoing sprint.

Moreover, there is a lack of a structured change evaluation approach that helps in making an appropriate deci-

sion after a Functional Change (FC) request. The main objective of this paper is to propose a decision support

tool that assists the decision-makers to decide whether to accept, deny or defer a given FC request. For this

purpose, we use the COSMIC Functional Size Measurement (FSM) method to evaluate a FC request. We

distinguish between a FC affecting an ongoing sprint and a FC affecting an implemented sprint. Based mainly

on the functional size of the proposed FC and the development progress, we provide recommendations to the

decision-makers.

1 INTRODUCTION

The success of software organizations increasingly

depends on how to manage software projects in a dyn-

amic and unpredictable environment, where software

requirements are likely to change. In fact, software

products are frequently subject to continuous evolu-

tion induced by the addition of new functionality or

the deletion/modiﬁcation of existing ones. Multiple

causes may be the reason for requirements changes

(e.g., missing functionality, defects corrections, etc.)

(Bano et al., 2012).

Agile methods are increasingly being adopted in

software organizations. They are ﬂexible and can

cope with software evolution. In fact, agile methods

encourage the communication with the customer/user,

who is present during each phase of the software life-

cycle. Although agile methods have the reputation

for coming up with ﬂexible solutions, many promised

software projects have failed to succeed. Gilb con-

siders that 61% of agile projects end up with failure

(Gilb, 2018). He also addressed the importance of

using measure in reviewing development progress, re-

evaluating user stories priorities, etc. This in order to

align with the new customer’s needs.

Over recent years, many agile methods have been

proposed (e.g., extreme programming, scrum, crystal,

etc.). Each organization chooses the most appropri-

ate method suitable to its work. Currently, eXtreme

Programming and Scrum methods are the most popu-

lar (Dikert et al., 2016). In our paper, we selected

“Scrum”. In the scrum process all the participants

(e.g., product owner, development team, scrum mas-

ter, etc.) should be keenly aware about how big is

a change request. In fact, a change considered as

“small” for the Product Owner (PO) may have signiﬁ-

cant impact on the development schedule and budget.

In practice, change requests are usually assessed

by “experts” that have the required knowledge about

the changed product and the process to carry out the

required modiﬁcations. However, software organiza-

tions should avoid as much as possible values that are

based on judgment (Abran, 2015), since there is no

guarantee of their effectiveness. Thus, it is necessary

to use a well deﬁned measurement method to assess a

change request.

In this paper, we introduce a new Functional

Change (FC) evaluation approach applied in scrum

process based on the COSMIC FSM method. Sizing a

FC in terms of COSMIC Function Point (CFP) units

482

Sellami, A., Haoues, M., Borchani, N. and Bouassida, N.

Orchestrating Functional Change Decisions in Scrum Process using COSMIC FSM Method.

DOI: 10.5220/0006853804820493

In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 482-493

ISBN: 978-989-758-320-9

will provide a real evaluation of the change request

(Haoues et al., 2017). This evaluation will help the

decision-makers responding to a change request. To

provide for these decisions, we distinguish between

a change request that affects an implemented sprint

and a change request that affects an ongoing sprint.

Nevertheless, in scrum process, changes are not al-

lowed after the sprint starts. However, if a change

affects a user story (not yet fully implemented) in an

ongoing sprint, this will cause either the sprint stop

or time-wasting in implementing a user story that will

certainly be changed in the next sprint as requested by

the PO. The proposed approach in this paper is sup-

ported by the Functional Change Measurement Tool.

The remaining of this paper is organized as fol-

lows: Section 2 presents ﬁrstly an overview of the

scrum process and COSMIC FSM method. Secondly,

it discusses some related works. In section 3, we use

COSMIC to evaluate a FC request. Section 4 pre-

sents the recommendations to answer a FC request. In

section 5, we illustrate our approach through the case

study “E-Commerce” and present our tool. Section

6 discusses several threats to validity, concludes the

presented work and outlines some of its possible ex-

tensions.

2 BACKGROUND

2.1 Overview of the Scrum Process

The scrum process starts with a high-level deﬁnition

of the project scope. Scrum uses the product backlog

as a list of features corresponding to the Functional

User Requirements (FUR). This list is prioritized by

the PO to be used as an iterative input for different

sprints “Iteration” (Schwaber, 2004). Thus, the active

involvement of the PO is mandatory to explain, eluci-

date the next iteration that should be implemented and

evaluate the work done. For a single sprint, four ty-

pes of meetings should be held: sprint planning meet-

ing, daily scrum, sprint retrospective meeting and

sprint review meeting. The FUR to be implemented

in a sprint are captured during the planning meeting;

the FUR to be selected are derived from the Product

Backlog and placed in a Sprint Backlog. Daily scrum

meetings are held during the sprint to discuss three

main questions: what has been done, what are you

going to do, and what are the issues (Cohn, 2004).

Each sprint is followed by a sprint retrospective meet-

ing during which the development team reviews the

sprint and decides which change will be made, and

how they can improve their work processes for the

next sprint.

Functional users:

Humans

Other software

Hardware devices

Functional

Sub-processes

Persistent

storage

Entry

eXit

Read Write

1 entering

data group

1 exiting

data group

1 retrieved

data group

1 data group

to be stored

Functional

process

Boundary

Figure 1: COSMIC data movements (COSMIC, 2017).

User stories represent a high-level of user require-

ments that typically express the FUR from an external

user perspective. A User Story (US) is a brief state-

ment of intent that describes the user demand. Below

the US description used in the literature (Cohn, 2004).

As a <user type>

I want to <feature or functionality>

so that <value or expected beneﬁt>

Typically, development team uses the User Story

Point (USP) method to determine the complexity of

user stories. This method has been widely critici-

zed (cf., (Berardi E., 2011), (Desharnais et al., 2011),

(Commeyne et al., 2016), etc.). USP is only meaning-

ful for a speciﬁc development team and in a speciﬁc

project. It could not be used to compare the producti-

vity of the organization with its competitor in the mar-

ket. In addition, (Commeyne et al., 2016) proved that

using COSMIC in agile projects gives a better results

in estimating the effort needed to accomplish a US.

2.2 COSMIC FSM Method: ISO 19761

COSMIC measure the software functional size from

the FURs. FURs represent the “user practices and

procedures that the software must perform” (COS-

MIC, 2017). Each FUR involves a number of functio-

nal processes. Each Functional Process (FP) consists

of a set of functional sub-processes that move or ma-

nipulate data. A data movement moves a single data

group from/to a user (respectively Entry and eXit data

movement) or from/to a persistent storage (respecti-

vely Read and Write data movement). One CFP is

then assigned per data movement. The functional size

of a FP is equal to the number of its data movements.

Thus, the software size is equal to the sum of the sizes

of all its functional processes.

COSMIC is the only FSM method that measure

the size of a change to software. COSMIC deﬁ-

nes a Functional Change (FC) as “any combination

of additions of data movements or of modiﬁcations

or deletions of existing data movements” (COSMIC,

Orchestrating Functional Change Decisions in Scrum Process using COSMIC FSM Method

483

2017). To measure the Functional Size of a FC, refer-

red to as FS(FC), COSMIC recommends to attribute

one CFP for each changed data movement regardless

of the change type (addition, deletion, or modiﬁca-

tion). Thus, the FS(FC) is given by the aggregation of

the sizes of all the added, deleted and modiﬁed data

movements. The FS(FC) is at least equal to 1 CFP

with no upper limits (COSMIC, 2017). Whereas, the

functional size of the software after a FC is given as

the sum of all added data movements minus the functi-

onal size of all removed data movements (COSMIC,

2017).

2.3 Related Work

Agile methods embrace change while traditional pro-

cess avoid changes. To determine the perception of

practitioners about product backlog changes, (Alsa-

lemi and Yeoh, 2015) conducted a survey that iden-

tiﬁed 11 reasons for requirements change. The main

reasons are: defect ﬁxing, functionality enhancement,

and design improvement. Regarding the change type,

the practitioners consider that 56.1% of the requi-

rements changes propose to add new requirements.

While, 62.9% of the requirement changes in the pro-

duct backlog propose to modify existing require-

ments.

Taking into account the importance of change ma-

nagement in scrum, a number of researchers have ad-

dressed the evaluation of requirements change in agile

methods. For instance, (Lloyd et al., 2017) addressed

the problem of requirements changes during the deve-

lopment process in distributed agile development. In

this study, a feature tree approach is proposed with a

supporting tool to help managing requirements’ chan-

ges in distributed agile development. On the other

hand, (St

alhane et al., 2014) proposed to analyze the

impact of technical changes (i.e., changes affecting

non-functional requirements or project requirements

and constraints), in particular, safety requirements.

The safety requirements have been separated and ana-

lyzed after any change that occurs to ensure the vali-

dity of safety requirements. Two main questions have

been addressed in this study: will the requirement and

design affect the safety? and Will the update affect the

safety?.

Table 1 summarizes the main proposals that fo-

cused on the requirements change in scrum process.

We noticed that some studies focused on functional

changes (cf., (Alsalemi and Yeoh, 2015)) while other

studies focused on technical changes (cf., (St

alhane

et al., 2014)). However, changes in these papers have

been always considered as new requirements. Thus,

no change history is recorded. However, we believe

that it is important to evaluate requirements’ changes

and record changes history. This will certainly help

during the software maintenance as well as for new

software development. It guarantees a better under-

standing of the change and directly affects the quality

of the software size measurement results (Desharnais

et al., 2011). Moreover, change evaluation is usually

based on experts’ judgment. Whereas, experts’ judg-

ment evaluation is less transparent compared to any

other technique and depends mainly on the experts’

experiences. In addition, there is no way to verify the

logic of their evaluation especially when there is no

quantiﬁed data (e.g., the change size).

3 FC EVALUATION IN SCRUM

PROCESS

This section illustrates how to evaluate a FC in scrum

process using COSMIC FSM method. Thus, we pro-

pose a detailed US description that provides the requi-

red information to apply COSMIC. Then, we present

measurement formulas to measure the functional size

of software products using US format. Later, we des-

cribe our method that can be used in evaluating a FC.

3.1 Detailed US Description

In scrum, user requirements are represented in user

stories format. However, user stories represent the

user requirements at a high level of details (Deshar-

nais et al., 2011). Moreover, there is no standard

representation of user stories. Hence, different user

stories description formats have been proposed. For

instance, (Verwijs, 2016) distinguished between two

ways to break down user stories: horizontal and verti-

cal. The horizontal breakdown divided the user sto-

ries by the type of work that is needed or the lay-

ers or components that are involved (Taibi et al.,

2017). Whereas, the vertical breakdown decomposed

the user stories in “a way that smaller items still result

in working, demonstrable, software” (Verwijs, 2016).

(Desharnais et al., 2011) used COSMIC to assess the

quality of the US documentation. They proposed a

documentation quality rating scale including ﬁve va-

lues. The evaluation of the user stories documentation

is based on whether or not it includes information that

can be used to identify COSMIC concepts. They con-

cluded that guarantying the US quality may guaranty

the measurement results quality as well.

In our study, we detail a US in a way that repre-

sents all the required information to apply COSMIC

FSM method. Consequently, the reﬁnement between

the existing description of user stories in section 2.1

ICSOFT 2018 - 13th International Conference on Software Technologies

484

Table 1: Summary of the proposals focused on requirements change in scrum process.

Study Focus Type Findings

(Alsalemi and

Yeoh, 2015)

Product backlog change manage-

ment and requirement traceability

Survey Lack of requirement change

traceability

(Lloyd et al.,

2017)

Requirements change management

in distributed agile development

Experimental A supporting tool

(Commeyne

et al., 2016)

Evaluation of teams’ productivity

using COSMIC

Experimental COSMIC is more reliable in

estimating models with much

smaller variances

(St

alhane

et al., 2014)

Impact of technical changes in sa-

fety requirements

Exploratory A supporting tool that ensures

the validity of safety

This Study Evaluation of functional changes in

scrum process using COSMIC

Exploratory Quantify FC request to help

the decision-makers

/*description*/

As a <UserType> I want to <Action> <Object> so

that <value or expected benefit> <NFR>

/*Scenario description*/

<User/System> <ActionType: Entry, Read, Write,

eXit, Expletive> <DataTransferred> <Action>

Figure 2: Detailed user story description format.

and COSMIC method leads to the new description

that we proposed in Figure 2, where:

• <UserType> is the user of the US referred to as

the functional user in COSMIC.

• <Action> and <Object> are used to replace the

concept “feature or functionality” in the US des-

cription provided in section 2.1. In fact, the “fea-

ture or functionality” is a combination of an action

and an object that the action will be applied on.

These two concepts are important in analyzing

and ﬁnding similarities between different user sto-

ries. This distinction is required when measuring

the functional size of a US. For example, consi-

dering the US “as customer I can log-in to my ac-

count”. The <Action> in this US is then “log-in”.

And the <Object> is “customer”.

• <value or expected beneﬁt>: It is used to charac-

terize the successful ending of the US. This infor-

mation is used to distinguish between two functi-

onal processes.

• <NFR> describes the non-functional require-

ments.

<value or expected beneﬁt> and <NFR> are op-

tional.

Two different user stories could not have the same

combination of <UserType>, <Action>, <Object>,

and <value or expected beneﬁt>. Although this des-

cription represents more details compared to the old

one, it do not represent the functional sub-processes.

Hence, moving to the scenario description is requi-

red. At this level, we will be able to identify the sub-

processes. We distinguish the following concepts:

• <User/System>: three main types are identiﬁed

such as external actor, system and data storage.

External actor could be a human actor (e.g., ad-

ministrator, client, etc.) or an external system in

a direct relation with the software to be measu-

red. The system that represents the software to

be measured. Finally, the data storage that allows

the retrieving and saving of data (e.g., databases,

XML ﬁles, memory cards, etc.).

• <ActionType>: the action that will be applied on

a certain data group is restricted to a number of

known verbs (e.g., select, ask, read, etc). These

verbs could be classiﬁed into four main corpses:

entry actions, read actions, write actions, and exit

actions. These corpses are provided in the Appen-

dix. These actions represent the data movements

in each US.

• <DataTransfered>: represents the data that

have been transferred in each functional sub-

process. They can be either input or output

data. This depends on the <ActionType> and

the <User/System>. <DataTransfered> in COS-

MIC corresponds to the “data group” concept.

• <Action>: gives a summary of the user story pur-

pose.

As an example, lets consider the following user

story (US1):

As an <Administrator> I want to <add> <a

Customer>

The priority of US1 is equal to P1. The impor-

tance of US1 is Essential. And the status of US1 is

“done”. The functional size of US1 is equal to 4 CFP.

The detailed measurement results are provided in Ta-

ble 2.

Orchestrating Functional Change Decisions in Scrum Process using COSMIC FSM Method

485

Table 2: Detailed measurement results of the functional size of US1.

Functional

User

US Detailed Description Data

Group

Objects

of interest

Data Mo-

vement

Type

CFP

The administrator asks to add a customer - - - -

The system displays the interface - - - -

Administrator The administrator enters the data of the cu-

stomer

customer

data

customer Entry 1

- The system checks the existing of the client customer

data

customer Read 1

- The system inserts the data customer

data

customer Write 1

Administrator the system displays error/ conﬁrmation

message to the administrator

error

message

error eXit 1

FS(US1) = 4 CFP

3.2 Prioritizing User Stories

In scrum, user stories are prioritized as requested by

the PO (Ambler, 2014). The development team starts

the implementation with the more prior US. Whereas,

PO does not have enough knowledge about the im-

plementation details. For instance, it is not possible

to buy a product without login-on as a customer. The-

refore, we propose to balance the US for PO and de-

velopment team perspectives according to two para-

meters: importance (developers perception) and pri-

ority (PO perception). The priority of user stories is

deﬁned by the PO. The US that must be implemented

ﬁrst is the more prior one (i.e., P1 is more prior than

P2, P2 is more prior than P3, etc.). The importance

of a US can be Essential or Desirable. Essential user

stories represent the basic user needs (Fairley, 2009).

Desirable user stories add values to the software (Fai-

rley, 2009). For two user stories with the same pri-

ority, the developers start with the Essential one. If

two user stories have the same priority and the same

importance, the developers will start with the US ha-

ving the minimum functional size. For example, a US

with importance = Desirable and priority = P1 (i.e.,

(D, P1)) indicates that this US is Desirable for the de-

velopers but very prior to the PO. Hence, it may be

selected after all the user stories with importance =

Essential and priority = P1 (i.e., (E, P1)).

Figure 3 is used to help prioritizing user stories

in the product backlog/sprint. Hence, it can be used

when selecting user stories from the product backlog

and when re-organizing user stories in an on-going

sprint after an approved FC. The importance/priority

of the changed user stories is compared to the impor-

tance/priority of the user stories initially in the sprint.

For example, suppose that a FC proposes the addition

of a US with importance = Essential and priority = P1.

If this FC is accepted, the added US must be imple-

mented before the user stories initially selected in the

sprint with a priority lowest than P1 (i.e., P2, ...Pn).

On the other hand, developers identify the status

of a US that can be used to control the development

progress of a US. Thus, the status of a US can be:

• New is the status of a user story in the product

backlog.

• To do is the status of a user story assigned to an

on-going sprint.

• Doing is the status of a user story currently being

implemented.

• To test is the status of a user story ready for tes-

ting.

• Done is the status of a user story tested with

success.

In our FC evaluation approach, we consider that

only two status are sufﬁcient (done and undone).

Thus, a US with New, To do or Doing status is not

fully implemented. Whereas, a US with Done or To

test status is fully implemented. Hence, we keep these

two US status: undone and done as given in Figure 4.

Where an undone user story is not fully implemented.

And, a done user story if fully implemented.

3.3 Measuring the Software Functional

Size from its US Descriptions

This section proposes measurement formulas that can

be used to measure the software Functional Size (FS)

based on the description of its user stories. Note that

the FS of the product backlog can be different from

the FS of the increment product. In fact, changes

always happen in the scrum process. Hence, new

ICSOFT 2018 - 13th International Conference on Software Technologies

486

(D, P1) (E, P1)

(D, Pn)

Developers

perception

PO perception

High

Low

High

Importance level

Priority

level

(E, P2)

(E, Pn)

(D, P2)

Figure 3: Prioritizing user stories in product backlog/sprint.

Figure 4: Adapted user stories status in scrum process.

functionality may appear, while others may be mo-

diﬁed or deleted. The functional size of the product

backlog is given by measuring the sizes of all sprints

initially identiﬁed. While, the functional size of the

increment product depends on the functional size of

the implemented sprints.

The functional size of the product backlog or the

increment product is equal to the sum of the functi-

onal sizes of all the sprints it includes (see Equation

1).

FS(P) =

∑

i=1

FS(S

) (1)

Where:

• FS(P) is the functional size of the product backlog

or the increment product.

• FS(S

) is the functional size of sprint i.

• n is the number of sprints initially identiﬁed in the

case of product backlog size measurement or the

number of implemented sprints in the case of in-

crement product size measurement.

The functional size of a sprint is equal to the sum

of the functional sizes of all the user stories it includes

(see Equation 2).

FS(S

) =

∑

j=1

FS(U S

i j

) (2)

Where:

• FS(S

) is the functional size of sprint i (1 ≤ i ≤ n).

• FS(US

i j

) is the functional size of the user story j

in S

• n is the number of user stories in sprint S

The functional size of a user story is equal to the

sum of the functional sizes of its actions (see Equation

3).

FS(U S

i j

) =

∑

k=1

FS(Act

i jk

) (3)

Where:

• FS(US

i j

) is the functional size of the user story j

in S

• FS(Act

i jk

) is the functional size of action Act

i jk

i j

(1 ≤ i ≤ n and 1 ≤ j ≤ m).

• p is the number of actions in user story j.

3.4 Research Method

Accepting or rejecting a FC request depends on two

main factors: the FS of the changed US and the US

status (done or undone). In fact, the FS(FC) gives

a real evaluation of the FC (Haoues et al., 2017). A

change in an ongoing sprint, in an implemented sprint

or in the product backlog may be handled with or wit-

hout extra cost/time. Consequently, every FC needs

to be evaluated. In our study, we evaluate a FC pro-

posed in an ongoing or an implemented sprint. This

evaluation is used later to provide recommendations

to the decision-makers to accept, defer or deny a FC

request.

In Figure 5, we present the different phases of this

study. In scrum, a FC request is proposed by the PO or

the development team. First, it should be expressed in

terms of US format to identify the changed US (noted

by USa). This later has a current status which is either

done (i.e., the change is in an implemented sprint or

an ongoing sprint) or an undone user story (i.e., the

change is in an ongoing sprint). In the case of an on-

going sprint, we identify the attributes of the sprint

where the change occur (e.g., size, start date, etc.) and

measure respectively the FS(FC), the FS(USa) and the

functional sizes of all the undone user stories in the

same sprint. In the case of an implemented sprint, we

measure the FS(FC) and the FS(USa). These measu-

res are used to evaluate the FC and provides guideli-

nes to orchestrate decision making (i.e., accept, deny

or defer a FC request).

3.4.1 FC Evaluation in an Ongoing Sprint

At the moment when a FC appears, an ongoing sprint

may contain both done and undone user stories. Thus,

if the status of the changed user story (USa) is undone,

our method proposes to compare the FS(FC) to the

functional size of all the undone user stories in the

Orchestrating Functional Change Decisions in Scrum Process using COSMIC FSM Method

487

- Accept

- Deny

- Defer

FC request

- Product Owner

- Development team

Express FC in terms

of User Story

Identify the affected

User Story USa

[USa in an implemented

sprint]

[USa in an ongoing sprint]

Identify the attributes

of ongoing sprint

[USa status = done]

Measure FS of

undone USs

Measure FS of FC

Measure FS of USa

Measure FS of FC

Measure FS of USa

[USa status =

undone]

Evaluate the

Make the

decision

Evaluate the

Figure 5: Phases for the FC request evaluation in the scrum process.

Table 3: Evaluating a FC request where USa status = un-

done.

Low Moderate High

1 CFP 2 CFP ≤ FS(FC) ≤

FS(US undone)

FS(FC) >

FS(US undone)

Table 4: Evaluating a FC request where USa status = done.

Low Moderate High

1 CFP 2 CFP ≤ FS(FC) ≤

FS(USa)

FS(FC) >

FS(USa)

same sprint. Hence, different baselines will be used to

control the status of the FC (see Table 3). Whereas, if

the status of the USa is done, we compare the FS(FC)

to the functional size of USa.

A “High” FC is a change with a functional size

bigger than the total functional sizes of undone user

stories in the same sprint. It will have a potential im-

pact on the software development progress. However,

the functional size of a “Low” FC is equal to 1 CFP.

This change can be handled without any impact on the

software development progress. Whereas, a “Mode-

rate” FC is a change with functional size lowest than

the functional size of undone user stories in the same

sprint. It will produce few changes in the software

development progress.

3.4.2 FC Evaluation in an Implemented Sprint

An implemented sprint in the increment product in-

clude a number of done user stories. Hence, a FC af-

fecting a done US means that the work that has been

already done must be changed. Thus, an additional

time and effort may be required to handle the change.

A “High” FC is a change with a functional size

bigger than the functional size of the changed user

story in the implemented sprint (USa). An important

effort may be required to implement this change. Ho-

wever, the functional size of a “Low” FC is equal to

1 CFP. This change can be handled without any re-

quired effort. However, a “Moderate” FC is a change

with functional size less than the functional size of the

user story affected by the change in the implemented

sprint. A little effort may be required to implement a

“Moderate” change.

4 DECIDING ON A FC REQUEST

Software functional size can be used not only

for effort/cost estimations but also for making-

decisions (e.g., budget decision, portfolio decision,

etc.) (Abran, 2010). In this section, we provide some

recommendations for the decision-makers (cf., pro-

duct owner, development team and the scrum master)

that can be used to help in making decision regarding

a FC request. Recall that a FC may affect either an

ongoing sprint or an implemented sprint. These deci-

sions are as follows:

• Accept the FC request which means implement

the FC in the current sprint.

• Deny the FC request which is made only if the FC

proposes a new software (re-start the development

from the beginning).

• Defer the FC request to the next sprint means

accept the FC and implement it in the next sprint

not in the current one.

4.1 FC in an Ongoing Sprint

Algorithm 1 provides recommendations that can be

used in making decisions when the FC is a modiﬁca-

ICSOFT 2018 - 13th International Conference on Software Technologies

488

tion and affects a US in an ongoing sprint. These re-

commendations are based mainly on the comparison

between the FS(FC), the functional size of all undone

user stories in the current sprint (noted by FS(US un-

done) in Algorithm 1), and the functional size of the

changed user story (noted by FS(USa) in Algorithm

1). For instance, if the FS(FC) is greater than the to-

tal sizes of all the undone user stories in the current

sprint, we suggest to defer the FC. Hence, the chan-

ged user story is deleted from the current sprint and

added after modiﬁcation with respect to the change to

the next sprint. In the case where the FS(FC) is less

than the total sizes of all the undone user stories in the

current sprint, it is required to compare the FS(FC) to

the FS(USa) before the change (noted by FS(USa)i in

Algorithm 1). Thus, if the FS(FC) is greater than the

FS(USa)i, we suggest to defer the FC, and the USa

after the change (noted by (USa)f in Algorithm 1) is

added to the next sprint. Whereas, if the FS(FC) is

less than the FS(USa)i, the decision will be made ba-

sed on the impact of the change on the FS(USa)i. In

the case where a FC proposes the addition of a user

story without changing any user story in the sprint, a

comparison must be done between the FS(FC) and the

functional sizes of all the undone user stories in the

sprint. Hence, if the FS(FC) is less than the FS(US

undone), the FC is accepted. Otherwise, the FC is de-

ferred to the next sprint. A deletion FC request do not

have any affect on the development progress.

4.2 FC in an Implemented Sprint

To carry out a FC in an implemented sprint, it is requi-

red to discuss the change with the PO. In fact, chan-

ging an implemented sprint means re-work (i.e., re-

doing a work that already has been done as requested

by the PO). In the case of an implemented sprint, we

suggest to deny the change. However, in order to sa-

tisfy the PO needs, we provide some analysis that al-

low the PO to determine the importance of the change

such as a comparison between the time spent in im-

plementing the changed user story and estimate the

required time to re-develop the user story after the

change. These analysis are provided in Algorithm 2.

Hence, this algorithm do not provide recommendati-

ons to answer a FC request but it provides some war-

nings to remember the PO about the importance of the

FC, whether it is really needed or not.

5 CASE STUDY AND TOOL

In this section, we demonstrate the application of our

approach on a case study “E-commerce” web site.

Algorithm 1: Deciding on a FC in an ongoing

sprint.

Aim : Deciding on a FC in an ongoing

sprint

Require: FS(FC), FS(US undone), and

FS(USa).

Ensure : Recommendations

1 begin

2 if FS(FC) > FS (US undone) then

3 defer the FC to the next sprint;

4 delete (USa)i from ongoing sprint /*

(USa)i is US before the FC */

5 add (USa)f to next sprint /* (USa)f is

US after the FC */

6 else if FS(FC) ≤ FS(US undone) then

7 if FS(FC) > FS(USa)i then

8 defer the FC to the next sprint;

9 delete (USa)i from current sprint;

10 add (USa)f to next sprint;

11 else if FS(FC) ≤ FS(USa) then

12 if FS(USa)f > FS(USa)i then

13 /* the FS(USa) after the

change is greater than the

FS(USa) before the change

*/ if remainingtime (USa)f ≤

requiredtime & teamprogress

= early then

14 accept the FC;

15 delete (USa)i from the

current sprint;

16 add (USa)f to the current

sprint;

17 else

18 defer the FC;

19 delete (USa)i from the

current sprint;

20 add (USa)f to the next

sprint;

21 else if FS(USa)f < FS(USa)i then

22 /* the FS(USa) after the

change is lower than the

FS(USa) before the change

23 accept the FC;

24 delete (USa)i from the current

sprint;

25 add (USa)f to the current

sprint;

26 else if FS(FC) = 1 then

27 accept the FC;

28 delete (USa)i from the current sprint;

29 add (USa)f to the current sprint;

Orchestrating Functional Change Decisions in Scrum Process using COSMIC FSM Method

489

Algorithm 2: Deciding on a FC in an implemen-

ted sprint.

Aim : Deciding on a FC in an

implemented sprint

Require: FS(FC), FS(USa), USa priority,

priorities P, FS(USs), devtime, USa

real DevTime

Ensure : Warnings

1 begin

2 FC percentage = FS(FC) * 100 div

FS(USa)

3 Avr DevTime =

∑

devtime div

∑

FS(USs)

4 if USa importance = Essential then

5 alert (you are going to change an

Essential User Story with + FC

percentage) ;

6 else if USa priority < P(n div 2) then

7 alert (This FC could highly impact

other user stories as it was

implemented in an early phase) ;

8 else if Avr DevTime < USa real DevTime

then

9 alert (this US took more time in

development then the average time

needed to accomplish a US with the

same functional size. It may contain

extra data manipulation) ;

5.1 Case Study

The case study “E-commerce” is developed by a team

of engineers. The web site allows the customer to

buy computer equipments on-line. This product has

been delivered after six sprints each one lasts for two

weeks. It includes initially ten user stories. The initial

detailed measurement results are given in Table 5.

The development team deﬁned the ﬁrst sprint

backlog by choosing the user stories organized accor-

ding to their importance/priority. US5, US6, and US7

have been implemented during the sprint S1. All the

user stories have the importance = Essential and the

priority = P1. In sprint S2, and based on the impor-

tance/priority of user stories in the product backlog,

US4, US8, US9 and US10 have been chosen to be

implemented in S2. As mentioned in Table 5, US4 is

with importance = Essential and priority = P2. Whe-

reas, US8, US9 and US10 are with importance = Es-

sential and priority = P3. Hence, the development

team starts by US4.

By the end of the implementation of US4, the PO

proposes to add (US 11, US 12, and US 13). Where:

the FS(US 11) = 4 CFP, FS(US 12) = 3 CFP and

FS(US 13) = 3 CFP. The importance/priority for all

Table 5: Detailed Product Backlog.

User

Stories

FS(US) Status Importance Priority

US 1 3 CFP New Desirable P3

US 2 3 CFP New Desirable P3

US 3 3 CFP New Desirable P3

US 4 3 CFP New Essential P2

US 5 4 CFP New Essential P1

US 6 6 CFP New Essential P1

US 7 6 CFP New Essential P1

US 8 3 CFP New Essential P3

US 9 3 CFP New Essential P3

US 10 6 CFP New Essential P2

the added user stories is (Essential, P2). Note that

the status of the user stories initially in the sprint are:

US4 status = done and US8 status = US9 status =

US 10 status = undone. The question here is whet-

her to accept the FC and implement it in the current

sprint (S2) or defer the FC to the next sprint (S3). In

this case, the FC affects an ongoing sprint and propo-

ses the addition of three user stories without changing

any user story in the sprint. The total functional size

of undone user stories is equal to 12 CFP. While, the

FS(FC) is equal to 10 CFP. We need to classify the

user stories (initially in S2 and new ones) according to

their importance/priority (see Figure 3). For this pur-

pose, we compare the importance/priority of the new

user stories (US11, US12 and US13) with the user

stories already in S2 (US4, US8, US9, and US10).

Hence, the user stories will be organized as follow:

US4, US11, US12, US13, US8, US9 and US10. The

user stories coming from the FC appear in the begin-

ning of the list. Thus, by applying Algorithm 1, we

make the following recommendations.

• Accept US 11, US 12, and US 13.

• Defer US 8, US 9, and US 10 to the next sprint

S3.

5.2 Tool

Algorithm 3 is used to measure the FS of a given US.

An action is characterized as a data movement if it

includes a verb presented in one of the corpses in the

Appendix.

Figure 6 gives some snapshots of the proposed

tool in this paper. The productivity of the develop-

ment team during the sprints is given in Interface 1.

As it is displayed in this interface, the productivity

of the team decreases to 6 CFP/hour in sprint S4. On

the other hand, the number of done user stories during

the past sprints is equal to 80% of the initially deﬁned

user stories. It remains only 20% of user stories to be

implemented during the next sprints.

ICSOFT 2018 - 13th International Conference on Software Technologies

490

Interface 2 is used for making recommendations

after a FC request. For instance, after ﬁnishing the im-

plementation of all user stories (from US1 to US16)

the PO suggests a new FC that proposes to delete

US10. US10 has been already implemented in sprint

S3. The functional size of US10 is equal to 6 CFP and

the implementation of US10 has been done in seven

days. Moreover, this user story presents a fundamen-

tal requirements. According to Table 4, this FC is a

“Medium” change. The FS(FC) is exactly equal to

the FS(US10) which is 6 CFP. Thus, by applying Al-

gorithm 1 we suggest to accept this FC.

Algorithm 3: Measuring the FS(US).

Aim : Measure the functional size of a

user story

Require: US is the user story to be

measured.

Ensure : SizeUS is the functional size of US.

1 begin

2 Size US = 0;

3 if User/System = External User & action

= corpusEntry & datagroup != Empty

then

4 data movement type := entry;

5 SizeUS := SizeUS + 1;

6 else if User/System = System & action =

corpuseXit & datagroup != Empty then

7 data movement type := exit;

8 SizeUS := SizeUS + 1;

9 else if User/System = System & action =

corpusWrite & datagroup != Empty

then

10 data movement type := write;

11 SizeUS := SizeUS + 1;

12 else if User/System = System & action =

corpusRead & datagroup != Empty then

13 data movement type := read;

14 SizeUS := SizeUS + 1;

6 CONCLUSION AND THREATS

TO VALIDITY

This work proposed a decision support tool for me-

asuring the Functional Size of User Stories in terms

US15, US6, and US 6 have been implemented in S1.

US4, UC11, UC12 and UC13 have been implemented in

S2. US8, US9 and US10 have been implemented in S3.

US14 and US15 have been implemented in S4. US1, US2,

and US3 have been implemented in S5. Finally US16 has

been implemented in S6.

of CFP units using COSMIC FSM method. In addi-

tion, functional changes are measured and evaluated

so that the decision-makers will be guided to decide

which FC request should be accepted, deferred or de-

nied. The proposed approach in this paper has been

illustrated through the case study “E-commerce”. Ho-

wever, the validity of the above results are subject to

two types of threats (internal and external) (Wohlin

et al., 2000):

• The internal validity threats are related to four is-

sues. The ﬁrst issue affecting the internal validity

of our approach is its dependence on a detailed

description of the user story; such details may not

always be available. Thus, for further work, we

consider that approximate/rapid FC evaluation is

required especially for an urgent FC request. The

second issue is related to the productivity of the

development team. In fact, two functional proces-

ses with exactly the same functional size do not

require always the same development time. Mo-

reover, the rapidity of the development team at the

beginning of the sprint and the end of the sprint

are not the same (this depends on the development

team skills). Thus, for further work, we will use

the structural size measurement proposed by (Sel-

lami et al., 2015) for more precise evaluation (i.e.,

to take into account the data manipulations). The

third issue is related to the evaluation of the FC

which is based only on the FS(FC) without taking

into account the FC type (delete, addition or mo-

diﬁcation). However, we consider that this factor

is important in the evaluation of a FC request. Fi-

nally, in this study we did not take into account

the relationship between the user stories. In fact, a

FC affecting a use story may lead to an impact on

the functional size of other use stories. For further

work, we will focus on the relationships between

user stories and change propagation.

• The external validity threats deal with the possibi-

lity to generalize the results of this study to other

case studies including the usability of the propo-

sed tool and the decision algorithms. The ﬁrst is-

sue is the limited number of case studies used to

test the proposed tool. In fact, only one case study

has been used: the ‘E-commerce”. Thus, testing

the proposed tool and algorithms in an industrial

environment is required in order to get the feed-

back from the practitioners.

Orchestrating Functional Change Decisions in Scrum Process using COSMIC FSM Method

491

Figure 6: Snapshots of tool with the case study “E-commerce”.

REFERENCES

Abran, A. (2010). Software Metrics and Software Metro-

logy. IEEE Computer Society.

Abran, A. (2015). Software Project Estimation: The Fun-

damentals for Providing High Quality Information to

Decision Makers. Wiley-IEEE Computer Society Pr,

1st edition.

Alsalemi, A. M. and Yeoh, E. T. (2015). A survey on

product backlog change management and require-

ment traceability in agile (scrum). In the 9th Malay-

sian Software Engineering Conference (MySEC), pa-

ges 189–194.

Ambler, S. W. (2014). User Stories: An Agile Introduction.

Bano, M., Imtiaz, S., Ikram, N., Niazi, M., and Usman, M.

(2012). Causes of requirement change - a systematic

literature review. In EASE 2012.

Berardi E., Buglione L., S. L. S. C. T. S. (2011). Guideline

for the use of cosmic fsm to manage agile projects,

v1.0.

Cohn, M. (2004). User Stories Applied: For Agile Software

Development. Addison-Wesley Professional.

Commeyne, C., Abran, A., and Djouab, R. (2016). Effort

Estimation with Story Points and COSMIC Function

Points: An Industry Case Study.

COSMIC (2017). The COSMIC Functional Size Measure-

ment Method, Version 4.0.2, Measurement Manual.

Desharnais, J. M., Kocaturk, B., and Abran, A. (2011).

Using the cosmic method to evaluate the quality of

the documentation of agile user stories. In 2011

Joint Conference of the 21st International Workshop

on Software Measurement and the 6th International

Conference on Software Process and Product Measu-

rement, pages 269–272.

Dikert, K., Paasivaara, M., and Lassenius, C. (2016).

Challenges and success factors for large-scale agile

transformations. Journal of Systems and Software,

119(C):87–108.

Fairley, R. E. (2009). Managing and Leading Software Pro-

jects. Wiley-IEEE Computer Society Pr.

Gilb, T. (2018). Why agile product development systemati-

cally fails, and what to do about it!

Haoues, M., Sellami, A., and Ben-Abdallah, H. (2017).

Functional change impact analysis in use cases: An

approach based on COSMIC functional size measu-

rement. Science of Computer Programming, Special

Issue on Advances in Software Measurement, 135:88–

104.

Lloyd, D., Moawad, R., and Kadry, M. (2017). A suppor-

ting tool for requirements change management in dis-

tributed agile development. Future Computing and In-

formatics Journal, 2(1):1–9.

Schwaber, K. (2004). Agile Project Management with

Scrum (Developer Best Practices). Microsoft Press;

1 edition.

Sellami, A., Hakim, H., Abran, A., and Ben-Abdallah, H.

(2015). A measurement method for sizing the struc-

ture of uml sequence diagrams. Information & Soft-

ware Technology, 59:222–232.

alhane, T., Hanssen, G. K., Myklebust, T., and Haugset,

B. (2014). Agile change impact analysis of safety cri-

tical software. In Bondavalli, A., Ceccarelli, A., and

Ortmeier, F., editors, Computer Safety, Reliability, and

Security, pages 444–454.

Taibi, D., Lenarduzzi, V., Ahmad, M. O., and Liukkunen,

K. (2017). Comparing communication effort within

ICSOFT 2018 - 13th International Conference on Software Technologies

492

the scrum, scrum with kanban, xp, and banana deve-

lopment processes. In Proceedings of the 21st Inter-

national Conference on Evaluation and Assessment in

Software Engineering, EASE’17.

Verwijs, C. (2016). 10 useful strategies for breaking down

large user stories (and a cheatsheet).

Wohlin, C., Runeson, P., Hst, M., Ohlsson, M. C., Regnell,

B., and Wessln, A. (2000). Experimentation in Soft-

ware Engineering: An Introduction. Kluwer Acade-

mic Publishers.

APPENDIX

Entry Corpus: These verbs express Entry data-

movements: Assign, change, choose, click, create,

edit, give, input, modify, provide, re-enter, select, sub-

mit, type, update.

Exit Corpus: These verbs express eXit data-

movements: display, edit, list, output, post, present,

print, return, send, Show update, view.

Read Corpus: These verbs express read data-

movements: ﬁnd, get, obtain, post, read, recognize

retrieve, Validate, Verify.

Write Corpus: These verbs express write data-

movements: add, archive, change, create, deﬁne, de-

lete, edit, insert, record, register, remove, save, store,

Update.

Orchestrating Functional Change Decisions in Scrum Process using COSMIC FSM Method

493