Unlike the old development process models, agile provides flexible methods adapted to requirements change. Although, agile methods such as Scrum are widely used today, an important number of agile projects end up in failure. This is due mainly to inaccurate estimates of time and lack of a structured change control process. However, tracking and controlling changes is important for a better project control. The main objective of this paper is to propose a tool for change controlling in scrum process. For this purpose, we use the COSMIC Functional Size Measurement method for a precise quantification and rapid evaluation of a change request. Reporting, tracking, and controlling the change status per project at different levels of details will certainly help in future projects management.
Software projects are undoubtedly hard to manage. In fact, software products are more
complicated compared to other products due to their invisibility, complexity,
conformity, and changeability [
Among the different Software Life-Cycle (SLC) models, managers select the
appropriate one depending on the project nature and the team skills. At the beginning of the
SLC, user requirements are often unclear, ambiguous, and not entirely defined. Hence,
the risk of changing user requirements during the software development is highly
predicted. However, the cost of a requirements change at an early phase of the SLC is
relatively low compared to the cost of changing requirements at a later phase [
Unlike the oldest SLC models, agile methods such as scrum embrace requirements
changes. In fact, they allow active collaboration between development teams and
customers (i.e., product owners). The Product Owner (PO) reports the requirements in an
unstructured way when talking to the development team [
User requirements are classified into three categories: Functional User
Requirements (FUR), Non-Functional Requirements (NFR), and Project Requirements and
Constraints (PRC) [
This paper proposes a tool for FC control in scrum process. This tool is based mainly on sizing FC using the COSMIC FSM method. The remaining of this paper is organized as follows: Section 2 presents firstly an overview of the scrum process, Functional Size Measurement (FSM) and COSMIC FSM method. Secondly, it discusses some related works. In section 3, we describe the change control process. In section 4, we illustrate our process through the case study “E-Commerce” and present our tool. Section 5 discusses the limitations and concerns of the change control process. Finally, section 6 concludes the presented work and outlines some of its possible extensions. 2 2.1
Scrum process allows a better communication between the development team and the
PO. For a successful scrum project, the development team must learn how to manage
themselves efficiently. In addition, the PO must be actively involved in every single
phase of the software development. Scrum appears to work better with small projects
that require five to nine persons in a development team including designers, developers
and testers. Nevertheless, some companies adapt scrum for large-scale projects [
The scrum process, illustrated in Fig. 1, starts with a high-level definition of the
project scope. Scrum uses the product backlog as a list of stories created by the PO
based on their initial requirements. These stories may increase or decrease in size based
on decisions made throughout the software development. The list of stories is prioritized
by the PO to be used as an iterative input for different sprints (Iterations) [
For a single sprint, four types of meetings should be held: sprint planning
meeting, daily stand up meeting, sprint retrospective meeting, and sprint review meeting.
The stories to be implemented in a sprint are captured during the planning meeting.
They are selected from the product backlog according to their priorities and placed in
a sprint backlog. In practice, usually, only the first two or three sprints are identified
and planned. Daily stand up meetings are held during the sprint to discuss: what has
been done, what are you going to do, and what are the issues [
As we mentioned previously, scrum uses the user stories to represent the user
requirements at different levels of details. A User Story (US) is a requirement written in
a specific way illustrating the type of user, feature or functionality that the user want to
do in order to realize some benefit [
This description identifies Who will do the US or find it valuable <user type>, What it can be used for <feature or functionality>, and Why it is valuable or important <value or expected benefit>.
Typically, development team uses the User Story Point (USP) to determine the
effort required for the accomplishment of a US compared to other user stories in the same
product backlog. Although its popularity, USP is not a good estimation technique. It has
been widely criticized (cf., [
Software size measurement throughout the SLC is used mainly for estimating the software development effort/cost and in driving decisions on the development project activities. The FSM methods measure the software size from the FUR. Functional Point Analysis (FPA) is the first FSM method proposed by Allan Albrecht in 1979. FPA 4 is supported by the “International Function Point Users Group” and ISO since 2003 (IFPUG-ISO 20926:2009). Thereafter, researchers proposed several methods to improve the original FPA method such as Nesma, MK II, FiSMA, and finally COSMIC.
COSMIC considers that a FUR involves a number of functional processes. Each Functional Process (FP) is detailed by a set of sub-processes of two types: data movement and data manipulation. A data movement moves a data group from/to a functional user (respectively Entry and eXit data movement) or from/to a persistent storage (respectively Read and Write data movement). Software size is measured by counting one CFP (COSMIC Function Point) for each data movement. The size of each FP is measured separately. The sizes of all functional processes are added to provide the software size.
Boundary
Functional process Functional users: Humans Other software Hardware devices 1 entering data group Entry 1 exiting data group
Functional
Sub-processes eXit
Read Write 1 retrieved 1 data group data group to be stored
Persistent storage
COSMIC is the only FSM method that measure the size of a change to software. It
defines a FC as “any combination of additions of data movements or of modifications
or deletions of existing data movements” [
Given the importance of change management in the agile context, a number of research
studies have addressed the requirements changes in scrum process. For instance, Lloyd
et al., addressed the problem of requirements changes during the development process
in distributed agile development [
In scrum, there is no standard US representation. Thus, different templates have been
proposed mainly to describe what the users will need the software for. In addition, user
stories are used at a high level of details [
In general, a US could have finer or coarser granularity than functional processes. That is a US could be a fraction of a FP or a set of functional processes. In our study, we consider that each US is associated to a FP. Thus, two user stories could not have the same [<UserType>, <Action>, <Object>, and <value or expected benefit>]. The US description in Fig. 3 provides more details in comparison with the old one. But, it does not represent the functional sub-process. Hence, moving to the scenario description is required to apply COSMIC. At this level, we distinguish the following concepts: – <User>: External actor could be a human actor (e.g., moderator, customer, etc.) or an external system in a direct relation with the software to be measured. – <ActionType>: the action that will be applied on a data group is restricted to a number of verbs (e.g., select, read, etc). These verbs are classified into four corpses: entry actions, read actions, write actions, and exit actions (see Appendix). These actions represent the sub-process in each US. Thus, a sub-process can be a data movement or a data manipulation. This depends on whether or not it transfer data. – <DataTransfered>: represents the data that have been transferred in each subprocess. <DataTransfered> in COSMIC corresponds to the “data group” concept. – <ActionDefinition>: gives a summary of the user story purpose. 3.2
Algorithm 1 is used to help prioritizing user stories in the product/sprint backlog. 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 a change.
In scrum, user stories are prioritized as requested by the PO [
Aim : Prioritizing user stories Require: P(US) the priority of user story (US).
Imp(US) the importance of user story (US).
FS(US) the functional size of user story (US).
Ensure : User stories organized by taking into account their priorities and importances first of all and then their functional sizes. 1 begin 2 if Imp(USi) = Imp(USj) & P(USi) != P(USj) then 3 Select the more prior user story ; On the other hand, developers identify the status of a US that can be used to control the development progress. Thus, the status of a US3, as shown in Fig. 4, can be: – New is the status of a US in the product backlog. – To do is the status of a US assigned to an on-going sprint. – In Progress is the status of a US currently being implemented. – To Verify is the status of a US ready for testing. – Done is the status of a US tested with success in the customer environment.
As it is described in [
New
To Do
In Progress
To Verify
Done This section proposes a set of formulas that can be used to measure the software size based on the US description. It must be noted that the FS of the product backlog can be 3 https://www.dreamstime.com/stock-illustration-scrum-task-kanban-board-sticky-noteswhiteboard-post-agile-software-development-hanging-tasks-team-image91765825 – FS(Si) is the functional size of sprint i (1 i n). – FS(USi j) is the functional size of the user story j in Si. – m is the number of user stories in sprint Si.
The functional size of a user story is equal to the sum of the functional sizes of its actions (see Equation 3).
p FS(U Si j) = å FS(Acti jk) k=1 (1) (2) (3) different from the FS of the increment product. In fact, changes always happen. Hence, new functionality may appear, while others may be modified or deleted. The FS of the product backlog is given by measuring the sizes of all sprints initially identified. While, the FS of the increment product depends on the sizes of all the implemented sprints.
The functional size of the product backlog or the increment product is equal to the sum of the functional sizes of all the sprints it includes (see Equation 1). n FS(P) = å FS(Si)
i=1 – FS(P) is the functional size of the product backlog or the increment product. – FS(Si) is the functional size of sprint i. – n is the number of sprints initially identified in the case of product backlog size measurement or the number of implemented sprints in the case of increment 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).
m FS(Si) = å FS(U Si j) j=1 8
Where: Where: Where: – FS(USi j) is the functional size of the user story j in Si. – FS(Acti jk) is the functional size of action Acti jk in USi j (1 – p is the number of actions in user story j. i n and 1 j m). 3.4
To avoid any trouble in the project progress, following a control change process is important. Fig. 5 illustrates our change control process. It starts when a change request is submitted. A change request is documented in order to give a detailed description of the change. A well change documentation must include the following items: – Statement of the need: identify clearly the changed item that must be analyzed. – Reasons for the change: describe the causes for changing user requirements. – Conditions of Success: the requester define what he expects from the change.
The documented change is submitted to the project team. The change revision with
the team is required especially for complex change. In our previous work [
impact analysis [Defer or Deny] 3. Prioritizing US and Making decisions Decision [Accept] 5. Update documents (product backlog, increment product, etc.) 7. Review and
Testing
6. Implementation 4
The “E-commerce” is a web site developed by a team of engineering students. The web site allows a customer to buy computer equipment on-line. It includes initially ten user stories. After discussing their priority and measuring their sizes, these user stories are initially classified into three sprint: S1(US5, US6, and US7), S2(US4, US8, US9, and US10), and S3(US1, US2, and US3). The initial measurement results are given in Table 2. By applying our formulas in section 3.3, the total size of “E-commerce” is equal to: FS(“E-commerce”) = FS(S1) + FS(S2) + FS(S3), where
FS(S1) = FS(US5) + FS(US6) + FS(US7) = 4 CFP + 6 CFP + 6 CFP = 16 CFP 10
FS(S2) = FS(US4) + FS(US8) + FS(US9) + FS(US10)
= 3 CFP + 3 CFP + 3 CFP + 6 CFP = 15 CFP FS(S3) = FS(US1) + FS(US2) + FS(US3)
= 3 CFP + 3 CFP + 3 CFP = 9 CFP Hence, the FS(“E-commerce”) is equal to 16 CFP + 15 CFP + 9 CFP = 40 CFP.
US 1 US 2 US 3 US 4 US 5 US 8 US 9 US 10
Applying Algorithm 1, US5, US6, and US7 have been selected in sprint S1. Table 4 provides the detailed scenarios of these three user stories. As planned, the development team started by S1. The selected three user stories have been implemented in two weeks. They moved then to sprint S3. US1, US2, and US3 have been selected to be implemented in this sprint. As mentioned in Table 2, the priority of these user stories is equal to P2. Whereas, the importance of US1 is Essential and that of US2 and US3 is Desirable. Hence, according to Algorithm 1, the development team starts by US1.
By the end of implementing US1, the PO proposes to add US11, US12, and US13
(see Table 3). The priority for all the added user stories is P2 and their importance
is Essential. The status of user stories initially in S3 are: US1 status = done and US2
status = US3 status = In Progress. The question here is whether to accept the FC and
implement it in S3 or defer the FC to the next sprint S2. In this case, the FC affects an
ongoing sprint and proposes the addition of three user stories. The total FS of undone
user stories is equal to 6 CFP. While, the FS(FC) is equal to 10 CFP. We classify the user
stories (initially in S3 and new ones) using Algorithm 1. For this purpose, we compare
the importance of the new user stories (US11, US12 and US13) with the user stories in
S3 with status = in progress (US2 and US3). Hence, the user stories will be organized
as follow: US12, US13, US11, US2, and US3. The user stories coming from the FC
appear in the beginning of the list. Thus, by applying the Algorithm for FC decision
making in an on-going sprint in [
Administrator Administrator Administrator Administrator Administrator Administrator Administrator Administrator Administrator Administrator
Enter Verify Add Receive Select Read Receive Enter Save Receive Select Search Receive Select Delete Receive
Article Data Article Data Article Data E /C message Article ID Article ID Article Data Article Data Article Data E /C message Article ID Article ID Article Data Article ID Article ID E/C message trans- Status To Do To Do To Do
Entry 1 Read 1 Write 1 eXit 1 FS(US5) = 4 CFP Entry 1 Read 1 eXit 1 Entry 1 Write 1 eXit 1 FS(US5) = 6 CFP Entry 1 Read 1 eXit 1 Entry 1 Write 1 eXit 1 FS(US5) = 6 CFP 12 4.2
User requirements are the basis of software project. In agile, they are described by user stories. The US description is a valuable document for the development team. Hence, if user stories are poorly described, the software development/maintenance will be critically vulnerable. In fact, well detailed user stories are not always available in practice since they require much more time. However, the more time spent at the beginning of the process, the little time will be required later. Consequently, a detailed description of a US is needed. So that any change can be carefully monitored and reported.
On the other hand, COSMIC is a flexible method that readily fits into the scrum process. We proved in this study that COSMIC can be applied throughout the process even within an ongoing sprint. Functional changes can be requested at any time and evaluated any where for better decisions-making. Thus, COSMIC provides greater flexibility to scrum process without disrupt its structure. In addition, the proposed process can be extended for the hidden requirement and high level detailed requirement by using approximate measurement approaches. In the case of a technical change (i.e., a change is the NFR) that requires the implementation of additional FUR, the change is translated into functional change. Hence, it can be measured and evaluated using COSMIC.
The tool has been tested using one case study “E-Commerce”. In order to ensure the efficiency of our change control process, testing the tool and algorithms in an industrial environment is required. Feedback from practitioners is necessary to improve the tool. 6
In practice, changes in user requirements are inevitable and present a main issue. Any deviation from user requirements may lead to project failure or induce an extra effort and much time through the software life cycle to satisfy a change request.
This paper proposed an assessment tool that support a FC control throughout the scrum process. Our tool is based on a detailed description of user stories and their sizing with COSMIC. In fact, the evaluation of a change request and the decision made responding to the change are based mainly on its functional size and its impact on the development progress. This avoid any misunderstanding due to the subjective evaluation of the change (done mostly by developers). Hence, the proposed tool adds objectivity to the scrum process. It can be used by decision-makers to meet customer’s needs, identify problems in future projects, and estimating future software project effort.
For further work, we consider that approximate/rapid change evaluation is required especially for an urgent change request. In addition, we consider that it is required to use the proposed tool in real industrial environment.
Entry corpus: Assign, change, choose, click, create, edit, give, input, modify, provide, re-enter, select, submit, type, update.
Exit corpus: display, edit, list, output, post, present, print, return, send, Show update, view.
Read corpus: find, get, obtain, post, read, recognize retrieve, Validate, Verify. Write corpus: add, archive, change, create, define, delete, edit, insert, record, register, remove, save, store, Update.