Improving Effort Estimation in Agile Software Development Projects

City University London
MA/MSc in Information Systems and Technology
Project Report
2013
Improving Effort Estimation in Agile Software Development Projects
A case study of sizing users stories based on the COSMIC method
1

Gediminas Siuskus
Supervised by: Cristina Gacek
26/09/2013
2

By submitting this work, I declare that this work is entirely my own except those parts duly identified and referenced in my
submission. It complies with any specified word limits and the requirements and regulations detailed in the assessment instructions
and any other relevant programme and module documentation. In submitting this work I acknowledge that I have read and
understood the regulations and code regarding academic misconduct, including that relating to plagiarism, as specified in the
Programme Handbook. I also acknowledge that this work will be subject to a variety of checks for academic misconduct.
Signed:
3

Acknowledgments
I would like to thank my supervisor, Mrs. Cristina Gacek, for all her support, the insightful ideas and the feedback I have received
throughout my extensive master thesis project.
4

Abstract
A key principle in agile software development is to manage changing user needs at different phases of the software project
development cycle. It splits the development into smaller iterations (sprints) to keep both developers and customers focused on one
of them at the time. By planning and working on small consecutive iterations agile teams reduce uncertainty of changing user needs.
However this approach has its drawbacks too. It becomes hard for agile team to plan and estimate the whole project in advance
accurately as not much information is available. Therefore agile project planning turns into guesstimation of the effort required. It is
based on available information about the system requirements and resources available. This paper proposes a method to improve
the agile effort guesstimation by applying functional analysis to size user stories. A number of user stories from a media company are
obtained to conduct the case study. The COSMIC method is used to size the user stories in functional points. Next those
measurements are later applied to calculate the final project effort. The case study concludes that COSMIC user requirements sizing
method can improve effort estimation and benefit agile teams in planning projects.
Keywords: agile, effort estimation, user story, function points, COSMIC.
5

Table of Contents
Chapter 1: Introduction and Objectives
1.1 Background of the Project
1.2 Aims, Objectives and Outcomes
Chapter 2: Academic Context
2.1 Introduction
2.2 Overview of estimation theories
2.3 Agile development and estimation
2.3 COSMIC and Agile
2.4 Related work
Chapter 3: Methods
3.1 Research model
3.1.1 Historical Sample COSMIC measurement
3.1.2 Upfront case study approximate sizing
3.1.3. Case study COSMIC size measurement
3.1.4. Case study effort estimation
3.2 Data collection
3.2.1 Historical sample
3.2.2 Case study project
Chapter 4: Experimental analysis and Results
4.1 Historical sampled sizing in CFP
6

4.2. Initial case study project estimation
4.3. Case study COSMIC sizing and effort estimation
Chapter 5: Discussion of Results
Chapter 6: Evaluation, Reflections and Conclusions
6.1 Evaluation
6.2 Conclusions and Future Work
6.3 Reflections
References
Appendix A: Project Proposal for MSc in Information Systems and Technology
Appendix B: Historical sample COSMIC sizing
Appendix C: Case study project COSMIC sizing
Chapter 1: Introduction and Objectives
1.1 Background of the Project
Estimating effort of IT projects at the early stage of the project is a challenging task. It is hard to plan for every development task and
predict the outcome of the full software development cycle. One has to spend a lot of time and effort to plan and specify all the
software development requirements thoroughly how it is done in waterfall projects. The drawback is that lots of time is spent on
specifications rather than development. Also waterfall methodology does not cope well with changes of user specification later in the
project. For these reasons IT professionals are looking for other development project management methodologies, which address the
shortcomings of the waterfall approach. Lean software development is one of those methodologies.
7

The time spent on system specifications in waterfall is used for planning and implementation in Agile. Extreme Programming and
Scrum are the leading methodologies for agile projects’ implementation and planning. Following the Scrum methodology the
development is split into short 1-2 week sprints when developers work on finite list of tasks and user stories. In agile software
development user stories define the functions a business system must provide in an everyday language written by the product owner
(customer representative). Before every agile iteration, sprint planning takes place where developers together with product owner
discuss the user stories and estimate effort needed to develop them. Here developers apply their expert judgment to estimate effort
based on their previous experience. The estimation becomes a challenge when agile team has to estimate a project that has more
than one iteration and all user stories cannot be discussed thoroughly with the customer initially. The initial estimate is needed to plan
and budget development project at the starting phase. In this situation agile team performs quick and rough estimation for all
upcoming work based on the delivered user stories. Firstly such approach is very biased and based on the developers intrinsic
knowledge. And secondly agile team cannot predict accurately the effort due to missing detailed information from user specifications.
Due to subjective expert knowledge and not fully documented functionality the agile effort estimates have a tendency to be
inaccurate. Some of the researchers in the field even call it a ‘guesstimation’ instead.
1.2 Aims, Objectives and Outcomes
This study addresses the lack of accuracy and objective measure in agile. The overall aim of this project is to improve effort
estimation in agile projects by researching method to measure user stories. The goal of this research will be achieved by addressing
the following objectives:
1. Review of the relevant studies and academic papers on the topic of IT development projects estimation with the focus on the
agile;
2. Create a effort estimation model for the agile software development projects using users stories;
8

3. Build a historical repository to estimate benchmark measures for effort estimation;
4. Apply an effort estimation method in the case study;
5. Compare the expert and empirical model effort estimates together with the real effort required.
The tangible outcome of the project can be a model for an early stage agile project estimation based on the agile user stories. The
primary beneficiary of the findings is the company being investigated. Their IT project data will be analyzed and improvement
recommendations given for their future projects. The secondary beneficiaries are other IT companies using agile methods for their IT
development projects. It is important for every of those companies to estimate and plan their projects as accurate as they can. Finally
other researchers and investigators in this field can benefit from the insights and information provided in this study.
1.3 Methods and Work Plan
The aims and objectives of this project will be addressed by analyzing the data of the media company. A case study method is
chosen to investigate effort estimation in a real-world IT development project. The data for the study was collected from the
company’s IT project management and issue tracking database. It was a list of user stories (functional requirements) together with
their descriptions and comments from the development team members. In addition to descriptive and communicative project data
every user story had the a time prediction (estimate) and real (logged) effort needed for the development team. It was not possible to
get the same quality data from other companies for a comparison due to their privacy policies. The quantitative data (lines of code)
was not requested from the companies as the study focuses on the functional specifications and also this information cannot be
shared by the companies. The received software functional data from the media company concluded the study to be a case study as
research method. The next two chapters present the reasons and construct an academic method to be used for investigating the
case study data.
The academic project will be conducted based on the following plan:
9

● Week 1-3: literature review;
● Week 3-4: design of research model;
● Week 4-8: collection of data;
● Week 6-10: data analysis;
● Week 10-13: writing up the findings;
● Week 13-15: project revision and proofreading.
10

Chapter 2: Academic Context
2.1 Introduction
Chapter 2 addresses the first objective of the project: review the relevant studies and academic papers on the topic of software
project effort estimation with the focus on agile development. The first part presents an overview of the IT project estimation theories
to give a background of the problem domain. The second part looks closer at functional analysis theory and functional size
measurement method. In the third part, the COSMIC functional size measurement method will be presented. Its application to agile
projects will be assessed to provide the basis of the theoretical model of this project. The final part of Chapter 2 presents studies
found in the literature that have focused on agile project estimation. There the challenges and latest findings in this field will be
analyzed.
2.2 Overview of estimation theories
The most expensive component of computer system projects is software development. The most complicated and most
researched topic in this field is the software estimation (Jorgensen and Shepperd, 2007). Estimation is a process of determining the
amount of effort, resources and time needed to develop a software project with the available information at hand. There are many
estimation methods available in the market that is based on quantitative data such as productivity, project size and other factors
affecting the projects. Jorgensen and Shepperd in their extensive study of software cost estimation academic papers have identified
three major estimation approaches (2007):
● regression;
● expert judgment;
● function points.
11

The regression-based estimation approach is dominant among the studies approximating to around 50% of all the papers. The
researchers in those papers try to build, improve or compare regression model-based estimation methodologies. Regression models
use historical data of projects that have been completed. Regression equations are constructed using collected variables to predict
their impact for the software estimate (Boehm and Abts, 2000). The mathematical regression formulas are used to incorporate the
variables to estimate the software projects. As such, software development effort (y) is treated as a dependent variable of
independently predicted variables (x1, x2, etc.) as size, effort adjustment factors, scaling factors etc in the regression equation. It is
not easy to apply regression-based models in practice, as it needs to fulfill certain conditions: availability of large dataset, absence of
outliers, no missing data items and no correlation among the predictor variables (Boehm and Sullivan,1999). Major regression
techniques used to estimate software size and effort are ordinary least-squares (OLS) method, multiple linear regression, stepwise
regression, classification and regression trees, stepwise ANOVA, etc. (Foss et al., 2001). These techniques rely a lot on the
technology used and lines of codes written for the software projects. Due to the need of large datasets and extensive technological
variables the regression-based estimation approach cannot be applied to estimate the effort of this project case study. Moreover the
regression-based approach is not practiced in supporting estimates in agile development projects.
The second estimation approach is expert judgment. The experts are developers who use their accumulated experience to estimate
the project (Stamelos & Angelis, 2001). The development team that has been working on the same domain, similar size and scope
projects have a know-how that can be used for predicting a similar project based on their experience and intuition. This approach is
opposite to regression method, because the estimation process is primarily based on non-explicit and non-recoverable human
reasoning (Jørgensen, 2004b). The expert method is useful when no quantified or empirical data is available to make a software
project estimation (Boehm et al., 2000). Yet this estimate is only as good as the expert’s opinion, and there is usually no way to test
that opinion until the project is finished. Moreover, the method relies on an human intelligence whereas those years of experience do
not necessarily translate to high levels of competency in making correct estimates. Two most widely techniques used to capture and
structure expert judgment are the Delphi Technique (Rowea & Wright, 1999) and the Work Breakdown Structure (Jørgensen, 2004a).
12

Delphi Technique is addressed further in this paper as its principles are applied in agile software estimation during the discussion of
functional user requirements (Cohn, 2004).
The third method of projects estimation, called ‘Function Points’, was introduced in 1979 by A.Albrecht working at that time in IBM
(Albrecht and Gaffney, 1983). IBM company needed a software development estimation method, which could be applied to any
programming language universally. The Function Point method measures the size of a data-processing systems from the user’s point
of view to estimate development effort. It is independent of the development methodology or technology and of capability of the
project team developing the application. Function points are calculated from the application features that the developers have to
implement. Therefore, the functional size of the project can be estimated early in the development lifecycle, before coding starts
when software requirement specifications are available. After the pioneer studies of the function points method by Albrecht and
Gaffney (1983), functional software size measurement evolved into several variations. There are now five recognized functional size
measurement methods with their ISO standards approved by Organization for Standardization (Santillo, 2012):
● MarkII (ISO/IEC 20968:2002);
● NESMA: ISO/IEC 24570:2005);
● FiSMA (ISO/IEC 29881:2008);
● IFPUG ( ISO/IEC 20926:2009);
● COSMIC (ISO/IEC 19761:2011).
Out of these methods the latest one (COSMIC) will be applied in this study. ‘COSMIC’ stands for the Common Software
Measurement International Consortium. It is a group software measurements experts from around the world who in 1998 formed
consortium to improve the traditional function point measurement methods (COSMIC, 2007). Firstly the COSMIC method was chosen
due to it easy applicability to business applications. As it is based on the fundamental principles of software engineering and
measurement, the COSMIC method is easy to learn and implement. Moreover it is appreciated by software project managers due to
its ease of use and compatibility with modern software architectures. One more benefit of the COSMIC is its application in the early
13

stages of software project. The COSMIC function points can be applied to estimate software size from its requirements in the early
lifecycle of software development whereas it could be challenging for regression methods where lines of code is used. Finally
function points can be applied to any software development project independent of programming language and team’s work
methods.
2.3 Agile development and estimation
The agile development process (see Figure 1.) splits the entire software development project lifecycle into a number of successive
iterations (sprints) to speed up the shipping of code and improve communication between major stakeholders (Cohn, 2005). The
focus is the fast production of functioning software components with a better handling of uncertainties and unpredictability. In this
way, the agile software development makes developers more flexible and adaptable to manage software requirements during the
project lifetime. Therefore adaptability is the key characteristic of agile methods summarized by twelve founding principles in Agile
Manifesto (2001).
14

Figure 1. Agile development process - Scrum method
Software requirements in agile projects are documented with users stories (US) written by customers (Cohn, 2004). User story
communicates functionality that is valuable to the end user of the system. Every agile user’s story describes software functionality
following three ‘C’ requirements: 1) card, 2) conversation and 3) confirmation.
Card characterizes the brief format of the user story. A typical agile user story follows a concise template: as a < 1. User type> I want
to <2. feature/functionality> so that <3. value or expected benefit>. It may be formulated in many other different ways, but it should be
meaningful both to the team developing the feature and the customer requesting it. Developers are not able to write code using only
user stories and they need to discuss it with the customer. Conversation is the essence of user requirement and can produce many
outputs as models, notes, story maps. Here developers learn about the needs of the customer and discuss potential solutions among
themselves. In this way, ambiguity and uncertainty is minimized as the customer’s raw ideas are bounced around between the
developers who crystallize core elements needed to implement requests. Finally the confirmation part of user story requirements
15

delivers criteria against which the use case feature will be tested. It is a customer test, which gives developers a confirmation that the
requirement is implemented as requested.
When the requirements are documented as user stories, the agile team estimates the effort needed to implement them. The
estimation process in agile projects is demanding as it involves all the developers’ team. Agile estimation is built around the principles
of Wideband Delphi estimation, where the entire team working on the project engages in creating user story estimates. One example
of team estimation - is a card based approach called Planning Poker (Cohn, 2004). The Fibonacci Sequence numbers are used for
marking cards (0, 1, 2, 3, 5, 8, 13, etc.), which represent development effort estimate. The group also agrees in advance how those
numbers translate to direct programming hours or story points. When users’ stories are presented by the customer and discussed
initially by all the development team, every single member selects privately a card representing his/her estimate for the specific user
story. At the end all the cards are revealed and compared. When everybody or the majority of the team has the same estimate, next
user story is chosen. When the estimate varies, developers present their arguments for their given values and the next round of
poker is initiated until a majority estimation consensus is reached. Thus, in such interactive card game the collective team wisdom is
synthesized to reach consensus and conclude the estimation of the user stories. Nevertheless, Planning Poker is not very reliable,
because it is based on subjective developers’ personal judgment and experience, sometimes referred as guesstimation. Therefore,
those estimates are prone to biases and errors (Cohan, 2005). It is so, because agile teams do not use any formal analysis, e.g.
historical benchmarks or analogical projects done in the past. Thus, agile estimation could be improved using more reliable and
verifiable methods, which resemble the agile approach presented in the agile manifesto. Moreover, those methods can help agile
teams to deliver upfront estimates for the overall projects, which are needed to get the necessary budget for the projects.
2.3 COSMIC and Agile
The subjectivity of measurement in agile can be address by Function Points method. Some researchers argue that there is a
16

conceptual similarity between agile story points and Functional Points. They both measure functional side of the project regardless of
the technology used for the implementation (Trudel and Buglione, 2010). There are significant reasons why agile projects can benefit
from functional points measurements:
● measuring and benchmarking projects within and outside of an organization (software productivity);
● objective estimation for upfront budgeting and/or iteration planning;
● project monitoring and control;
● internal process improvement;
● enhanced collaboration between customers and developers.
An important challenge for using agile user story points within an organization is that effort cannot be benchmarked both internally
and externally to compare teams productivity. To address this issue it is essential to be able to measure the software size produced
as a work output using an ISO standard Functional Size Measurement approach method, such as COSMIC. Calculated COSMIC
function points (CFP) can be used for evaluating project productivity (CFP/hours) and benchmarking within the company. Externally
the CFP productivity can be compared with the International Software Benchmarking Standards Group extensive database
(ISBSG.org) storing data from new development and enhancement projects from all over the world. The COSMIC method makes
functional users requirements estimation objective and should produce more reliable effort estimates than using biased expert
judgment with subjective user story sizes.
2.4 Related work
In recent years there were a number of studies investigating the functional size measurement technique application to agile software
projects. It started when the IT industry began shifting from traditional waterfall development process, which was causing many
delays, towards agile development processes.
17

One of the earliest studies was done by Dumke et al. (2008) in Germany, interviewing IT industry experts about their usage of agile
development methods. The bottom up estimation procedure using users’ stories was found to be used mostly within the industry. The
authors proposed the use of function point analysis to validate experts estimated user stories. They suggested also that most
complex user stories can be identified and analyzed better with the help of functional points.
In another paper by Santana et al. (2011), after studying 2191 user stories in a Brazilian public agency, they drew a conclusion that
function points can are directly related with initial values of the story points after the planning poker.
Another group of researchers found that development teams practicing agile can use simpler linear methods such as functional point
analysis for determining the effort needed to implement needed functionalities. From all the functional point methods they have
singled out the COSMIC method, because it has the best correlation with the effort at the beginning of the software lifecycle -
planning and construction phase (Popovic and Bojic, 2012).
A recent study (Buglione & Trudel, 2010) suggested to apply functional points in agile projects at two different levels of granularity
due to different purposes and interests: iteration and project level. Functional points at the iteration level should be used by the agile
team, whereas at the project level it is more relevant for the organization management as they are more concerned with budgeting.
The researchers recommend the estimation of functional size of the project together with user stories in the product backlog during
the planning phase. Later at the end of the project the initial project functional size can be compared with the final size and stored in
the historical repository for further analysis and future project benchmarking and measurement.
Ergun and Gencel in their 2007 study state that there is no universally applicable estimation model and recommend the use of the
standard approach to estimate effort by evaluating two key components: the size of the software and the work rate, or so called
Productivity Delivery Rate (PDR).
18

Another recent study by Buglione et al. (2011) aimed to develop an improved software planning technique for Agile software projects.
Researchers suggested instead of agile guesstimation when playing planning poker, the use of functional point method to determine
project functional size. They advocated the use of COSMIC Function Points (CFP) for estimating functional size of the software,
because it improves accuracy and reliability of the effort planning for the project.
The study done by Berardi and Santillo in 2010 makes a similar conclusion. According to them , the use of functional point methods,
as COSMIC, benefits agile project management and improves the agile process itself. They agreed that adoption of COSMIC FSM to
agile development projects is beneficial in all project phases and it delivers accurate measurement results.
And the final study in the field that looks at the COSMIC model application in agile software development was conducted by
Fehlmann and Santillo (2010). They supported the notion that agile software development stakeholders need measurements that are
similar to traditional software. They claim that COSMIC functional points help teams to measure development effort to plan the
projects and size the software easily from the product backlog user stories.
Altogether these studies yield a common conclusion that effort guesstimation in Agile software development can be improved by
estimating functional size of projects using COSMIC.
19

Chapter 3: Methods
3.1 Research model
This thesis proposes to investigate the applicability of the function point based measurement method for effort estimation in real-life
agile software development case. It follows the suggestion from Jorgensen and Shepperd (2007), who stated that there may be much
to learn about software estimation from well-presented and well understood real-life cases instead of employing only historical
regression analysis. This study takes an agile software development case study and applies the functional sizing model (COSMIC) to
estimate and compare effort prediction with expert judgment. In addition, the study investigates an early sizing method, which can be
use complementary for the agile project planning in the inception of the inception stage. It should help agile teams to budget time
faster and easier having effort predicted quick and easy at the beginning of the development life cycle.
The figure 2 below depicts the visual sequence of the proposed research model. The research is divided into four stages:
1. Historical sample COSMIC size measurement – sizing historical sample user stories and calculating average user story
(AUS) together with average productivity (AP) measures;
2. Upfront case study approximate sizing – early estimating of case study project by applying AUS;
3. Case study COSMIC size measurement – sizing case study user stories in COSMIC function points (CFP);
4. Case study effort estimation – estimating both approximate and accurate effort needed to develop case study user stories.
20

Figure 2. Research model
Conducting research based on the model presented above, the study will investigate the following research questions:
● Q1: Can the COSMIC functional size measurement predict effort more accurately than expert judgment?
● Q2: Can the COSMIC approximate sizing be useful in the early agile project planning?
3.1.1 Historical Sample COSMIC measurement
The goal of the first research model step is an estimation of two measures for the further analysis. The first estimate is the
average user story (AUS) sized in CFP. It will be used for early case study approximate sizing. The second measure is average
productivity (AP) estimated in CFP per hour. The AP is a productivity measure, which will be used at the final stage of research when
calculating a case study development effort. Both of these rates will be calculated after the historical sample user stories will be sized
in CFP according to the COSMIC measurement manual guidelines (COSMIC, 2009). The whole sizing and calculation process is
divided into five steps:
21

1. Identification of user requirements;
2. Formulation of the functional processes;
3. Measuring user story COSMIC size in CFP;
4. Calculation of the average user story size in CFP;
5. Calculation of the average productivity in CFP/hour.
1. Identification of user requirements
If a company follows an agile methodology thoroughly this step can ignored, as software requirements are clearly specified in the
form of user stories. One does not need to read and investigate all software requirements to identify functional user requirements
there. In agile user stories collect functional user information and can be used straightly in COSMIC by skipping the first step.
User story template makes user requirements recognizable instantly:
As a <role>, I want to be able to <activity> so that <business value>. ‘Role’ represents the actor of the activity or the one who is
receiving a value from conducting that activity. ‘Activity’ informs the developers what the system must do to deliver needed ‘business
value’, which is optional to fill. Therefore the outcome of this step in agile is a list of user stories to be sized in CFP.
2. Formulation of the functional processes
After the review of user stories, the next step is to map out the functional processes from them. Developers investigate every
user story to identify their functional processes. Ideally in agile projects a single user story represent one system functional process
according to COSMIC guideline (2011). Yet in some cases one user story might have more than one functional process. The
conclusion of this step is a list of functional processes next to their user stories they represent.
22

3. Measuring user story COSMIC size in CFP
In the third step the COSMIC functional size measurement method is used to quantify user stories in CFP. The functional size
of the user story is the sum of its functional processes CFP values. Every functional process CFP value is calculated by identifying
data movements within the functional process and aggregating their number. Thus the agile user story size will be the sum of data
movements within functional process it represents. COSMIC identifies four types of data movements within functional process: Entry,
Read, Write, and Exit. These data movements represent how the information is moving from and towards the business application.
The graph below depicts this COSMIC data movement model:
Figure 3. COSMIC data movement types
Data movements within functional process are sized based on the COSMIC measurement standard. According to the COSMIC
measurement guideline, the standard size for one data movement is one CFP. Therefore each identified data movement is counted
as one CFP. Thus to size the functional process (agile user story) one has to aggregate all data movement CFPs. When user story
has few functional processes, their all CFPs are added up to get the COSMIC size of user story in CFP. Here is the mathematical
expression of this process:
23

Size (CFPi) = size (Entryi) + size (Readi) + size (Writei) + size (Exiti)
Σ Σ Σ Σ
For example, a functional process Y has one Entry data movement, two Read data movements, two Write data movements, and two
Exit data movements. So COSMIC size is counted this way:
Size (CFPY) = 1E + 2R + 2W + 2E = 7 CFPs
4. Calculation of the average user story size in CFP
When the CFP of each user story is estimated, it is time to calculate the average size of user story from the historical sample.
The average size of user story (AUS) is an arithmetic mean of all the user story sized in CFP:
Size (AUS) = size (USi) / N, where N – number of user stories.
Σ
The average size of user story will be applied later in the early estimation of the case study approximate size.
5. Calculation of the average productivity in CFP/hour
There are number of ways to determine team’s average productivity (AP) value. In one case the group of experienced experts in
COSMIC can agree on this value by discussing and evaluating the agile team, projects and technology used. The alternative way is
to use external repository and pick up the most feasible AP value. It is done by applying a project related filters such as such as
programming language, project type, application domain, team experience, etc. The third way is to derive it from an internal
repository of the previously implemented projects inside the company or team. For this project an internal repository was created
from the historical sample because neither experts nor external repositories were accessible at the time. The average productivity
rate is calculated using user stories functional sizes (CFP) and time spent by developers implementing them (logged hours). In
24

practice, the aggregated sum of all sample user stories’ sizes in CFP will be divided by the development hours:
AP (CFP/hour) = CFP (USi) / hours (USi)
Σ Σ
The value AP amount calculated will be used to estimate the approximate and accurate effort of the case study.
3.1.2 Upfront case study approximate sizing
The approximate functional process sizing is applied when functional user requirements are not fully specified or a quick sizing is
needed. In this situation the functional processes and data movements cannot be defined due to lack of information or time.
Therefore an approximate sizing method is suitable to estimate project effort when:
● not all the functional user requirements are specified , so called ‘early sizing’;
● a quick measurement is needed and there is not enough time to use a standard sizing method – ‘rapid sizing’.
This thesis investigates if agile teams can improve their planning by using approximate method sizing in the early stages of the
software development project. COSMIC recommends using early sizing in cases when locally-calibrated ‘scaling factor’ can be used
for converting user stories to CFPs. Therefore for the case study analysis the average user story from the historical sample is
applied. It should be remembered that when approximating, it is important to use both accurately-measured and similar local data for
the similar software projects, which approximate sizes will be measured.
The Average Functional Process approximation is conducted in three steps:
1. identification and summing up of all the functional processes (user stories) of the new project (e.g. 20);
2. using the sample average, the approximate size of the new project is calculated by performing mathematical multiplication:
aggregated number of user stories is multiplied by average user story sample size in CFP (20 x 5 CFP = 100 CFP);
25

3. Identify the uncertainty of approximate size of a new project by applying COSMIC estimation approach to a sample user stories;
the uncertainty is expressed as a percentage of the approximate size, e.g. ± 20%
To sum up, this functional size estimation method is less time consuming than the COSMIC size measurement approach, where data
movements needs to be identified and calculated. In this research the aim is to calculate the approximate COSMIC size and compare
it with the accurate COSMIC measurement.
3.1.3. Case study COSMIC size measurement
This stage of the research will follow the same plan and methodology described in the first section of the methodology
chapter. The dataset of the latest user stories will differ from the historical sample. The aim is to apply COSMIC measurement
approach to the most recent agile project, which has been implemented by the same team and same technology used as with
historical sample.
3.1.4. Case study effort estimation
This is the final stage of the research model where both approximate and accurate overall case study efforts are calculated. The
approximate effort is calculated using average user story whereas the accurate effort will aggregate users stories measured in CFP
independently.
The accurate functional estimation process will follow the pyramid model starting from the lowest base (functional process),
proceeding to the middle (user story) and finishing at the top (project). To calculate the effort of user story the functional process
(USiFPj), size in CFP is divided by the average productivity:
26

Effort (USiFPj) = CFPj : CFPj / hour (1)
where, the letter i is a user story identifier and j is a functional process identifier identified within the specific user story.
After the effort for every functional process has been estimated, the next step is to calculate the effort of individual users’ stories. The
efforts of user story functional processes’ are aggregated to get effort needed to implement that user story:
Effort (USi) = (2)
𝑖=1
𝑘
∑ 𝐸𝑓𝑓𝑜𝑟𝑡 (𝑈𝑆𝑖𝐹𝑃𝑗)
where, i identifies the number of the user story being investigated, j is the identification number of the functional process, and k is the
number of functional processes in a user story i.
The last step in the accurate effort estimation process is to aggregate all user stories’ efforts for the total project effort:
Effort (Projecta) = (3)
𝑖=1
𝑛
∑ 𝐸𝑓𝑓𝑜𝑟𝑡 (𝑈𝑆𝑖)
where, a is an identifier for the project, i is the identification for the user story, and n is the number of the user stories in the project a.
The approximate overall project effort calculation is simpler than the accurate one and requires only one equation of three multipliers:
● CFPs / hours – an average productivity rate calculated from the historical sample
● - the total number of users stories in the project estimated;
𝑝=1
𝑘
∑ 𝑈𝑆𝑝
● - an average user story functional size in CFP from historical sample
𝑠=1
𝑛
∑ 𝐶𝐹𝑃𝑠
𝑠=1
𝑛
∑ 𝑈𝑆𝑠
27

Approximate Effort (Projecta) = X : CFPs / hours (4)
𝑝=1
𝑘
∑ 𝑈𝑆𝑝 𝑠=1
𝑛
𝑠=1
𝑛
∑ 𝑈𝑆𝑠
2. Data collection
For this research a media company specializing in shipping business news delivery has been investigated. Functional user
requirements used for their software development projects were gathered from the last few years documented in Jira. Jira is an issue
and project tracking software developed by the Australian company Atlasian. Programming languages used in these projects were
Java, HTML, and JavaScript. An iterative agile software development framework (Scrum) for managing these projects was used.
Functional user requirements investigated in a form of low-level user stories were created in the early phases of the projects by the
product owner. These were later refined into the more detail during sprint planning between scrum team members: developers and
product owner.
There are two data sets used for the research project:
1. Historical sample of 36 user stories
2. Case study project of 28 user stories
3.2.1 Historical sample
Historical sample consists of 36 user stories that have been implemented by the developers during the period from 2010 to 2013.
The user stories chosen had to fulfill these requirements to suit project needs:
● have an initial estimate;
● have a description;
● have logged development hours;
● have been completed;
28

● have been developed by the same development team as case study project;
● have a single functional process (COSMIC, 2011).
The compiled list of user stories comes from a new software development and support projects. Such combination of user stories
from different projects makes this historical sample more flexible to use. It covers majority of system functionality. Therefore locally
calculate average user story size and average productivity are well applicable for the case study estimations.
3.2.2 Case study project
The latest agile team development project at the media company consisting of 28 user stories has been selected for the case study.
The company was intrigued by an alternative way to estimate the development effort easier and more objective. They offered their
latest project for the investigation. It was a project to build an upgrade authorization and authentication engine together with initial
customer portal for their online news subscribers. Initially estimated as 421 hours project it increased more than two times when it
was finished (1010 hours). Therefore they were very interested to apply a measurement tool that could improve their agile project
planning estimate.
At the beginning of the project product owner has compiled 28 user stories describing the new system requirements. Later during the
planning phase of the development every story has been discussed with the development team and estimated how much time it will
take to do it. All 28 user stories had to be estimated in advance, as the whole project has been managed by the internal steering
committee by major stakeholders, who requested to have the effort estimate at the start of the project. For this reason agile
development team has struggled a lot and spent much more time than expected for initial project estimation as they are used to
planning for iterations. Therefore having some historical benchmark data to assist agile team with the initial estimation has been
perceived by the company as a big benefit from this study.
29

The other reason why company gave access to their latest project was a method to estimate the software product for the product
owner. Usually product owners in agile just participate in the estimation planning to answer all the questions developers have
regarding the user stories. The management in this company believed that their product owners are technical savvy and can not only
answer the developers’ queries, but also come with their estimate of the project. In this way the customer representatives (product
owners) will participate more actively in the discussion by having the estimate based on the historical data. And moreover he/she will
refine user stories with a higher level to detail while estimating the functional size of the project. All in all, the estimation model
proposed in this project was accepted by the company as valuable learning opportunity worth sharing their data and their time.
30

Chapter 4: Experimental analysis and Results
This experimental analysis focuses on shipping news portal, where subscribers access maritime business news. Projects and teams
of engineers developing and supporting this global website are managed by the agile project management method - Scrum. User
requirements for this website are documented in a form of user stories. The user stories are written by a product owner who
represents the needs of company owning the website and customers reading the news. Preceding this year user stories are
investigated for creating a historical repository for benchmarking and estimating sizing ratios (average user story size and average
productivity) for the recently finished project (case study).
4.1 Historical sampled sizing in CFP
The first step in the experimental investigation of the model is to build a historical sample dataset by manually measuring the
COSMIC size of the functional processes in CFP. To do so, COSMIC measurement method is applied to investigate the sample of 36
user stories. The table below shows the general size characteristics estimated by the experts (agile development team) of these user
stories.
User stories Total Estimate Average Estimate Min Estimate Max Estimate
36 325 hours 9.03 hours 0.5 hours 60 hours
Table 1. The general statistics of historical sample
Functional Users
The first step for calculating user stories in COSMIC is identification of functional users. They are documented in the user stories
31

delivered by developers in agile sprints. Every user story in a sprint backlog has a user for whom described functionality must be
developed. From the functional point of view the user in a user story is functional user, because he sends and/or receives data.
Therefore identification of the functional users from the sample of 36 user stories is clear-cut as they follow recommended template,
where the user is identified at the first part of the sentence As a <type of user>. Here is an exemplary used case with identified
functional user: as a journalist, I want to make picture galleries to deliver so that readers would get richer content.
After reviewing functional users in the sample of 36 users’ stories these were identified:
● Advertiser - 3 user stories;
● Editor - 4 user stories;
● Journalist - 8 user stories;
● Salesman - 6 user stories;
● Subscriber - 15 user stories.
Functional processes
In the mapping phase of COSMIC measurement process, software functional user requirements (user stories in case of agile) are
used to identify three key elements: functional processes, objects of interest and data groups. Knowing these three key elements
helps to identify individual data movements used in sizing functionality.
In agile, the identification of functional processes is easy due to a standard user story template format. Following recommended agile
template, user story defines a single functional process according to the COSMIC Agile guideline (COSMIC, 2011). Let’s take an
example of a user story from the historical sample to understand how it is done: As ad salesman I want to search for articles by
categories, so that I can find out how many stories are written in a given period. In this user story functional user’s (salesman) goal
(underlined) is a functional requirement to conduct a specific search within an archive of the website. The verbal phrase of functional
user is the functional process - search archive by tags. Before naming it the COSMIC functional process, it has to be validated as
32

well. The validation of the functional process is conducted by answering the following questions (COSMIC, 2008):
● Is it unique and independently executable?
● Is it triggered by an event?
● Does the triggering event occur outside of the software boundary?
● Does the process finish all that is required to be done after triggering event?
These questions were used to validate the functional processes identified from the user stories. During the validation procedure
identified triggering events were recorded in the table listing COSMIC data movements of sample user stories (see Table 3 below).
Here is an example validation of the identified functional process:
Functional Process 3 = Search archive by tags
Question Answer Comment
Is it unique and independently executable? Yes
Is it triggered by an event? Yes Actor types a phrase in the
search
Does the triggering event occur outside of
the software boundary?
Yes Actor is outside the boundary
Does the process finish all that is required to
be done after triggering event?
Yes
Table 2. Functional processes validation #3 - Search archive by tags validation
33

The Search archive by tags process is therefore a valid COSMIC functional process. The same validation has been conducted for the remaining
functional processes identified from the user stories, which are presented in the table below.
User story Functional process
As a user, I would like to get RSS notifications of my keyword searches
in order to be updated.
Create search RSS feed
As a sales person, I want users with ARCHIVE subscription to access
archive articles.
Restrict archive access
As subscriber I want to search for articles by tags, so that I can find out
how many stories are written in a given period.
Search archive by tags
As a editorial, I want the newsletter to be automatically sent to
subscribers.
Send newsletter
As a user, I want more information before signing up for a subscription. Redirect to page
As a user I want to search for exact phrases and get search tips. Search content
As a journalist, I would like to make picture galleries. Create a gallery
As an administrator, I want to add subscribers to the fleet newsletters. Signup to newsletter
As a journalist, I want to export the hardcopy version to news website. Publish epaper
As a user, I want to get notification *When trying to enter an article
older than 14 days*.
Access archive article
As a search engine, I want to find pages quickly by accessing a
sitemap.
Optimize content
As a user I want multi fetching of ads to make page loading fast and
reliable.
Load ads
As an ad client, I want AdTech to place ads based on keywords. Place ads
34

As a salesperson, I would like potential clients to leave contact
information before downloading media information.
Create contact form
As a user, I want to search for articles from the paper and online on the
same page.
Search content
As a user I want the browser to remember my username and
password.
Remember user
As a user, I want to be able to sign up to a daily newsletter. Signup to newsletter
As an editor, I want to control what stories goes in the newsletter. Manage newsletter
As a reader, I would like access to the 100 Power list via Zmags. Access special edition
As a journalist, I would like to publish chartering report articles. Publish chartering report
As an administrator, I want to monitor users on "one free article"
subscriptions.
Monitor users
As a user, I would like the opportunity to read one extra article for free
per 24 hours.
Manages users
As a journalist, I want to see the article title in the URL. Optimize hyperlinks
As an advertiser, I would like a front page entry point to MyNewsDesk. Deliver MyNewsDesk feed
As a journalist, I want some articles to become free news after 14
days.
Create free 14-day article
As a editor, I would like Google News to have an access to the
subscription content.
Give access to bots
As a journalist, I would like to relate web-tv content to the news
articles.
Link video content
As a reader, I would like to subscribe to an RSS-feed clicking an icon
in the address field.
Subscribe to RSS
35

As a user I want to be able to access weekly newspaper. Access weekly newspaper
As a job seeker I want to see a recruitment article expiry so I don't
apply for it
Expire job posts
As an administrator, I want to export xls-files from the web database. Export database
As a journalist I want articles marked as 'free' to be freely accessible
for a user.
Label free articles
As a user, I would like to see all populated categories on jobs home
page.
Create job categories
As a user i would like a link on my mobile browser to get to the full site. Create a redirect
As a journalist, i would like to publish monthly magazine online. Import monthly magazine
As advertiser, i would like to advertise on top of mobile site. Enable mobile ad
Table 3. Functional processes of the sample user stories
Functional sizing
After all the functional processes have been identified, the last step is to size them in the COSMIC functional points (CFP). Each
functional process is sized by identifying the data movements of its input, process and output phases. It is achieved using a
recommended message sequence diagram (MSD) analysis method (COSMIC, 2007) . This method is applied to the input, process
and output phases of each functional process to identify movements of data groups. The exemplary functional analysis using MSD is
shown below:
36

Figure 4. Sizing a User Story with the COSMIC Method
The notation of the diagram is as follows:
● vertical line corresponds to a functional process;
● lines with arrows characterize data movements (E-entry, R-read, W - write, X - exit); the data movements appear in sequence
from top to bottom of the functional process; entry and read data movements are directing to functional process and exit and
write - outwards;
● labels next to the lines indicated data groups;
37

● a dashed line represents a functional user triggering a functional process.
The Message Sequence Diagram (MSD) presents visually relationships between functional process, data groups and data
movements. It also helps to apply COSMIC measurement function by combining functional sizes of individual data movements.
These are aggregated into a single functional size value in units of CFP by arithmetically adding them together:
Size (Search archive by tag) = size (E1) + size (R1) + size (W0) + size (X2) = 4 CFP, where 1 CFP (Cosmic Function Point) is
Σ Σ Σ Σ
defined as the size of one data movement (COSMIC, 2007).
All in all, user story functional sizing of the historical sample is conducted following the procedure recommended in COSMIC
guideline for business application software (COSMIC, 2007). In general, the functional sizing process combines two analyses:
1. Construction of a logical data model for the persistent data to identify objects of interest and their data groups
(Entity-Relationship analysis);
2. Analysis of all functional process phases (input, process and output) to identify data groups sent to/from persistent storage
and calculates input/output data movements.
Historical sample sizing results
The measurement details of the remaining user stories and their functional processes are presented in Appendix B. The
aggregated results of the sizing 36 user are:
Total CFP Entry Read Write Exit
118 39 56 36 50
Table 4. Total Number of data movements of the historical sample
38

From the four data movements the biggest one is read one, when data groups are requested from the persistent database. It indicates that
majority of functional processes and user stories retrieve data from the persistent storage.
Having the size measures of the sample user stories, it is possible to calculate now the two ratios for the further thesis investigation: 1) average
size of user story and 2) average team’s productivity.
The average size of the user story (AUS) is calculated dividing total size of user stories by the number of them:
𝑠=1
𝑛
𝑠=1
𝑛
∑ 𝑈𝑆𝑠
=
181
36
≈5. 03 𝐶𝐹𝑃 5. 03
The agile team’s average productivity (AP) is estimated dividing the total functional size of historical sample by development
hours that were spent to implement their user stories:
𝑠=1
𝑛
𝑠=1
𝑛
∑ 𝐻𝑜𝑢𝑟𝑠
=
181
662
≈0. 273 𝐶𝐹𝑃/ℎ𝑜𝑢𝑟
With these values of the average size of a functional process and agile team’s productivity data for a given business domain and a
given technology, an initial estimate can be made of the software project effort.
4.2. Initial case study project estimation
In agile projects before engineers start estimating and planning the software development, users should have prepared user stories.
At this stage a first estimate of the software project can be conducted when historical data is available to do so. It is called ‘early
sizing’ when a new project is estimated at beginning of the project lifecycle as part of planning process (COSMIC, 2007). The need to
have this estimate comes both from the customer and development team. It is necessary for the customer to plan and budget project
39

financial expenses and for the developers to provide a rough estimate how much that project might cost without spending much time
investigating project requirements in the detail. In an early life of the project only high-level artifacts such user stories exists. At this
point the functional size of these user stories is not measured but estimated using locally-calibrated ‘scaling factor’ within the
company. The ‘scaling factor’ used n this research is the average size of the user story. An early functional size (EFS) at the project
level is estimated using the estimated number of functional processes (user stories) multiplied by the locally-calculated average size
of a functional process (user story): EFS = USp x AUS. This framework is supported by COSMIC advanced guideline (C0SMIC,
Σ
2007).
The early functional size estimation is applied for the case study project consisting of 28 user stories. At an initial analysis the
estimate of the functional size is 141 CFP (28 user stories x 5.03 CFP/user story). To calculate the initial overall effort of the project,
benchmarking productivity data from the sample historical study is applied. The average productivity rate is used here knowing that
the same team of developers who worked on historical sample user stories developed the case study project. Thus, the overall effort
is estimated to be 518 hours (141 CFP / 0.273 CFP/hour). The early overall approximate project estimate is summarized in Table 5:
Issue Unit of
measure
Value
Overall
Approximate
Effort
Work-hours 518
Total
Estimated
size
CFP 141
Average
Productivity
CFP/hour 0.272
40

Table 5. Initial project estimation data
In addition to the approximate effort, an error interval is estimated to take into consideration the uncertainties of both size estimate
and productivity used from the historical sample. Given the uncertainty in the early approximation, an uncertainty level is calculated
by sizing a few user stories from the case study itself. The first three user stories from the case study are selected to compare the
actual and approximate sizes. Firstly the approximate size of these stories is estimated - 15 CFP (3 user stories x 5.03 CFP/user
story). Secondly the functional size of these user stories is measured using the COSMIC sizing methodology - 25 CFP. Finally the
comparison of the actual size (25CFP) with the initial approximate size (15 CFP) of the user stories gives the uncertainty of 40%. As
a result the final overall approximate size of the case study varies from 85 to 197 CFP (141 CPF 40%). Consequently the overall
±
approximate effort gets 40% uncertainty from 311 to 724 hours. All the values together with the uncertainties are recapped in the
Table 6.
Issue Unit of measure Value - 40% Value + 40%
Overall Approximate Effort Work-hours 311 724
Total Estimated size CFP 85 197
Table 6. Initial project estimation data including uncertainty
The 40% uncertainty is very optimistic error compared to the IT industry benchmark at the early phase of the project – industry
estimate variability ranges from -25% to +400% (McConnell, 2009). These benchmark values are taken from study by Boehm and
called the cone of uncertainty (McConnell, 2009). The cone of uncertainty summarized the uncertainties of estimation of software
development projects at the different stages of the life cycle. The case study uncertainty is smaller compared to the one suggested
by Boehm’s cone of uncertainty. Investigating further the 40% case study error fits in the third phase in the cone of uncertainty graph
- requirements completed (from -33% to +50%). This indicates a good accuracy and reliability of the approximate sizing model.
41

Nevertheless the true accuracy of the prediction will be tested later when the real and estimated data of the case study effort will be
compared.
Figure 5. The Cone of Uncertainty based on common project phases and milestones
4.3. Case study COSMIC sizing and effort estimation
At this section of the paper analysis and findings of the case study COSMIC sizing will be presented. It follows the same procedure
as it was applied for the historical sample COSMIC sizing. Therefore this section will analyze briefly the key steps without getting into
the.
Case study dataset
42

The case study project consists of 28 user stories, which were estimated by experts to take 421.5 hours of their development time.
The smallest user story is guesstimated with 2 hours and the biggest one with 38 hours of programming by the developers.
User stories Total Estimate Average Estimate Min Estimate Max Estimate
28 421.5 hours 15.1 hours 2 hours 38 hours
Table 7. The general statistics of case study project
Compared to the historical sample, the case study is a bigger project in size and the user stories on average are greater. Yet the
number of functional users is smaller, because it focuses mostly on one type of user (subscriber).The case study is software
development project to build a customer portal to give subscribers ability to manage their subscriptions. Therefore there are only two
functional users:
● Salesman - 3 user stories;
● Subscriber - 25 user stories.
These two types of functional users trigger the following functional processes:
User story Functional process
As a subscriber, I want to be authenticated with my
login information to access website. Logon
As a subscriber, I would like to access the digital
version of weekly newspaper. Access digital weekly newspaper
As a subscriber, i would like to get access to the Access online articles
43

online articles, which suits my subscription package.
As a multi user subscriber, i would like to get number
of access to the online articles at the same time
based on my subscription package. Access concurrently online articles
As a salesman, I want different concurrency limits on
different titles so I can sell more subscriptions.
Limit daily and archive articles
access
As a corporate subscriber, I want to login to the site
from an internal corporate network based on my IP
address. Authenticate IP-subscriber
As a subscriber, I want to login to the site directly from
an encrypted url so I don't need to type username and
password. Authenticate via encrypted URL
As a subscriber, I would like to access news content
via smartphone app. Deliver content
As a new subscriber, I want to have an option to order
two week free trial. Order trial
As salesman, I want to create a free trial and/or
subscription using CRM system. Create trial
As a new user, I want to order a full subscription so I
can get access to protected content instantly. Order subscription
As a passive subscriber, I want to renew my
subscription so I can instantly get access to protected
content. Restart subscription
44

As an authenticated user, I want to get access to an
overview of my saved profile data and active
subscriptions. Display profile information
As an authenticated user I want to edit contact info in
my profile. Edit profile information
As a user, I would like to see the most popular
customer service questions. Create FAQ
As a subscriber, I would like to pay for my outstanding
invoices using credit card. Pay invoice by credit card
As a user signing up for a new subscription, I want to
choose payment method so I can pay with credit card
immediately. Pay by card for subscription
As a subscriber, I want to see my latest invoices. Display latest invoice
As an authenticated user, I want to change my
password online. Update password
delivery address permanently.
Change delivery address
temporarily
delivery address temporarily.
Change delivery address
temporarily
As an authenticated user, I want to update a future
temporary address changes. Edit future address changes
As an authenticated user, I want to change my billing Update billing address
45

address.
As a user, I would like to save my login details to
prevent from entering it multiple times. Remember user
As a user, I would like to restore my forgotten
password. Restore password
As a user, I would like to contact customer service
with my question. Contact customer service
As a salesman, I would like to open the site when our
CRM system fails authenticating users. Disable login-wall
As a salesman, I would like all our CRM customers to
be imported into customer portal the first time they log
in. Automatic import
Table 8. Functional processes of the case study user stories
When all the functional process have been identified in the case study project, the final task is COSMIC sizing is to identify data
movements and data groups that move within the boundary of the functional process. In the same way as with the historical sample
the message sequence diagram is used for decomposing functional process. The first application of COSMIC sizing methodology on
the historical sample was very thorough due to lack of knowledge and practice. The second time when identifying data movements
for the case study the sizing process has been smoother. The COSMIC sizing of the every project user story is presented the
Appendix C. The table with the CFP sizes is missing sub-processes and data groups, which were presented in the historical sample
study. These elements were instantly identified when sizing after gaining experience from sizing the historical sample. Therefore the
goal was to make the sizing process of functional processes closer to the real-case business scenario when time is scarce at the
initiation stage of the project. Below are the summary of the case study COSMIC sizing results.
46

Total CFP Entry Read Write Exit
174 38 43 38 45
Table 9. Number of data movements of all functional processes (case study)
When compared to the historical sample, the case study is 21% bigger in CFP size. The agile developers predicted case study to be
30% bigger compared to the historical sample. In terms of CFP mean values the case study is bigger (174CFP/28=6.21 CFP)
compared to the historical sample (5.03CFP). It indicates that on average the case study project is more complex functionally.
Moreover it shows that the the COSMIC sizing process of user stories both in historical sample and case study is consistent.
Therefore it is beneficial that both sizing were conducted by the same person and following the same COSMIC guidelines.
Effort estimation
The next step after COSMIC sizing is calculating overall case study project effort estimated in development hours. For estimation the
team’s average productivity rate is used from the historical sample. The engineer’s team who worked on this project is the same that
worked on the historical sample and they used the same programming tools. Therefore it is the same productivity rate is applied for
calculating the overall effort needed to implement the case study software development project. The overall project effort is estimated
to be 640 development hours:
Issue Unit of measure Value
Overall Exact Effort Work-hours 640
Total Estimated Size CFP 174
Average Productivity CFP/hours 0.272
Expert predicted effort Work-hours 424 hours
Table 10. Overall case study project effort estimation results
47

The overall effort needed for the customer portal project development was estimated greater compared to the approximate value
(518 hours) excluding the uncertainty. The estimate is also bigger than the expert predicted effort size. The greater value can be
explained by more thorough analysis of the functional requirements as more details were discovered and taken into consideration.
On the contrary, the bigger figure can incorporate the sizing error, which can only be deducted after several of applications. As such
the possible sizing fluctuations could be reduced and present more accurate data. Nevertheless both conclusions can be evaluated
when comparing the findings with the real data, presented in the next chapter.
48

Chapter 5: Discussion of Results
In this study, the most common measurement techniques were evaluated and one of them applied to estimate the size and effort
needed for the implementing real agile software project. Estimated values of efforts were determined sizing software user stories
using COSMIC functional model. Table 11 shows summary of the effort estimates together with the real time spent by the
development team to implement the case study project.
Estimate method Work-hours
Overall Approximate Effort-40% 311
Estimated by Experts 424
Overall Approximate Effort 518
Overall Accurate Effort 640
Overall Approximate Effort+40% 724
Logged by developers 1011
Table 11. Summary of the results
The results presented in the table show that the closest effort estimate to the real number of hours spent for developing the software
was an overall approximate effort with 40% plus accuracy error (724 hours). The overall accurate effort measure calculated by sizing
every user story gave less accurate, but more reliable measure without a 40% uncertainty. Altogether both these effort estimates
based on COSMIC sizing of user stories predicted better than agile experts (424 hours). Therefore this study has answered the first
research question about the accuracy of COSMIC application to the agile. The effort predicted from COSMIC sized user stories was
closer to real time spent for the project by the developers. Moreover the second research question about the approximate sizing
49

application to agile proved to be feasible. Both in time needed and effort predicted the model proved to be advisable to use in the
future projects.
From the wider perspective of the measurement techniques presented at the beginning of this paper, the results prove the fact that a
more accurate prediction can be obtained when historical data is used. The results of the study support practical application of the
COSMIC sizing for agile user stories. Both the approximate initial effort and overall effort prove it with better estimation than experts.
From the other point of view it is hard to make any generalized conclusions from the findings, because the research investigated one
case study. The results imply that the usage of functional measurement and analysis can be successfully applied for predicting agile
software projects. Therefore agile teams can to try to compliment their expert estimates together with functional sizing to ease initial
estimation process and improve the effort prediction accuracy.
Besides the overall effort estimate, the other important result is calculation and application of average productivity rate (CFP/hour) in
the analysis. This measure proved to be a good indicator of agile team’s efficiency. It is a valuable productivity ratio for companies
interested in optimizing their processes. Measuring and tracking team’s productivity is important for every software organization. In
the long run this productivity ratio can be calculated after every development project to track the team’s effectiveness.
The last important finding of this study is feasibility of COSMIC sizing model application for sizing agile user stories. In this study
COSMIC sizing presented better effort estimates than experts’. The case study results show that estimates based only on functional
software size can give more accurate results when no nonfunctional characteristics of the system are included in the analysis. The
expert’s in their estimation process take into consideration both functional and technical factors such as technology, system’s
complexity and team’s competency. As such the experts’ estimate should be more accurate as they take more things into
consideration. Nevertheless the findings underline a great potential of functional software measurement presented in the paper.
Therefore it agile teams can really benefit when estimating projects to combine both functional and nonfunctional measures to
improve effort prediction.
50

Chapter 6: Evaluation, Reflections and Conclusions
It is generally accepted that the agile project management deals well with projects having high uncertainty and unpredictability. The
initial project estimation is the Achilles knee of agile teams. It is hard to plan and budget the time needed to execute the whole project
at the start as software is not documented thoroughly. The agile focus more on the implementation than rather documentation of the
software. Most of the estimation methods are suited for iterations, such as Planning Poker and Paired Comparisons. These
approaches are suitable for short iterations; however both of them just guesstimate the total project effort (addition of all iterations).
Therefore agile project plans depend on expert judgments and they are not that reliable when the subjective judgment instead of
facts is applied. As a result, agile project plans can be improved to be more reliable and applicable.
6.1 Evaluation
The goal of this project was to investigate how user stories can be analyzed and sized to improve agile project effort estimation. The
four objectives mentioned at the beginning of this paper were drawn to reach this goal. The goal has been achieved as each of four
objective been met with a success.
The first objective was to review the relevant studies in the field of IT project estimation with the focus on agile software development.
Chapter 2 addressed this objective and presented a comprehensive review of the literature relevant to this topic. During the
investigation of the literature few hints were found how the user stories can be used to improve the effort evaluation. The literature
study benefited with a better understanding of software estimation subject and its issues. Therefore it gave a good theoretical
jumpstart to dive into empirical analysis.
The second objective was to create an early estimation model focused on agile user stories. The research technique to evaluate
52

functional size of user stories has been chosen after literature review and evaluation of project data. The choice of the COSMIC
sizing method has been explained in Chapter 3. The COSMIC sizing method of user stories concluded in the more accurate overall
effort estimation compared to the experts’ predictions.
The third objective aimed at creating a historical repository to get productivity rates used for calculating project effort sizes. This
objective was met successfully with getting data (user stories) of historical user requirements together with their implementation
figures. How the functional analysis has been conducted was presented in Chapter 4. The outcomes of the historical study were two
measures: 1) an average functional user story size and 2) an average team’s productivity rate. Both of these rates contributed well
for estimating the effort needed to develop case study project. Chapter 4 addressed the third objective of this paper too – a real case
study of functional sizing and effort estimation. The aim was to conduct an initial case study estimation and thorough sizing of each
user story. The use of average size of user story allowed a quick initial calculation of effort needed. Further extensive analysis of the
case study presented with a more accurate effort estimate and concluded the objective.
The final objective was to compare estimated results (approximate and total effort) with the real time spent for the case study
implementation by the developers. This objective was addressed in Chapters 5 where results were presented and discussed. The
objective has been met as the case study estimates proved to be feasible in predicting effort needed for the implementation.
Moreover the fifth objective benefits from study results exposing areas of improvement for the future research.
Finally, the initial approximate sizing proved to be the quickest and easiest way to estimate the effort. With more data over time and
more experience, the average user story size can be used as a measure of productivity. It could serve as a very rapid sizing tool for
agile teams. As a consequence the projects might be started or cancelled faster knowing the approximate effort needed.
6.2 Conclusions and Future Work
53

The study discovered that COSMIC functional method can be applied to size agile user stories and improve their effort prediction.
When there is not much time available for project estimation and planning, approximate effort estimation can be conducted using the
average user story size. The results suggest that this method can give better results than expert estimate. In other case more
thorough COSMIC sizing of users’ stories can be performed with more reliable data. It has been also proved by the results to give a
closer estimate to the real effort needed.
To conclude, the study has achieved its aim to find the way how to estimate agile project more objectively by using user stories. The
method has been tested only with one case study so it is not possible to conclude that the COSMIC functional sizing gives a better
result for calculating effort. Meanwhile, the case study suggests that functional analysis can benefit the agile software prediction
guesstimation with more reliable and accurate model.
Subsequently, the results proved to be more beneficial for proponents of functional software analysis. The COSMIC estimated case
study predicted higher number of work-hours needed to implement the project compared to the experts’ estimate. Nevertheless to
prove validity of the statement further analysis must be conducted. Therefore there are several areas where this project can be
improved for the future research.
Firstly, the use of bigger dataset can improve credibility of the findings. The study has investigated just one project case study and if
more data would be available then the results could be more accurate and credible. To conduct such extensive empirical analysis the
longer time would be needed and greater number of companies included in the project.
Secondly, the estimation model can be improved incorporating functional analysis in the agile sprint planning. In this way both
non-technical and technical characteristics of the project could be blended in to get more accurate results. The functional analysis
would be conducted by the customer and presented to the technical to for the estimation discussion. So both technical (developers)
54

and business (customer) parts of the project can be contribute with a more constructive discussion.
6.3 Reflections
The research project was an interesting learning experience with quite successful results at the end. The investigation of literature
and estimation methods took more time than expected to get a good grasp of the subject. The functional sizing of both historical
sample and case study proved to be most challenging and rewarding at the end.
If I were to carry this project again, I would investigate other agile team project’s simultaneously for a better comparison and more
insights. It could be that investigated agile team lacked competence and experience in estimating agile projects. They have been
using Scrum for five years, but not following its principles entirely.
A second area of improvement could be possible automation of user story sizing. During the theoretical analysis I have encountered
few articles that used text mining technologies together with functional analysis. With this approach a much bigger sample size of
users’ stories and projects can be tackled to prove a statistical validity of the analysis.
On a whole, the personal project has been a satisfying learning experience with some mental challenges along the way. Having
experience as a product owner in agile, the subject was interesting and motivating to study throughout the project. This project has
been an initial attempt to apply functional analysis to agile project estimation. There are a great number of improvements that can be
done next. Therefore the findings of this study might benefit other agile project planning studies and body of knowledge surrounding
it.
55

References
Albrecht, A. J., & Gaffney Jr, J. E. (1983). Software function, source lines of code, and development effort prediction: a software
science validation. Software Engineering, IEEE Transactions, 6, pp. 639-648.
Beck K., et al., 2011. Agile Manifesto. http://www.agilemanifesto.org
Berardi, E., & Santillo, L. (2010). COSMIC-based Project Management in Agile Software Development and Mapping onto related
CMMI-DEV Process Areas. In International Workshop on Software Measurement–IWSM.
Boehm,B. W., & Sullivan K. J. (1999). Software Economics: Status and Prospects. Information and Software Technology, 41, pp.
937-946.
Boehm B. & Abts C. (2000). Software development cost estimation approaches – A survey. University of Southern California, Los
Angeles, CA 90089-0781, USA and IBM Research, 650 Harry Road.
Buglione, L., & Trudel, S. (2010). Guideline for sizing agile projects with COSMIC. Proceedings of the IWSM/MetriKon/Mensura,
Stuttgart, Germany.
Buglione, L., et. al. (2011). Improving Agile Software Projects Planning Using the COSMIC Method. VALOIR2011, Torre Cane, Italy.
COSMIC–Common Software Measurement International Consortium. (2007). Advanced and Related Topics.
COSMIC–Common Software Measurement International Consortium. (2008). Guideline for Sizing Business Applications Software
Using COSMIC-FFP.
COSMIC–Common Software Measurement International Consortium. (2009). The COSMIC Functional Size Measurement
Method-version 3.0 Measurement Manual (The COSMIC Implementation Guide for ISO/IEC 19761: 2003).
56

COSMIC–Common Software Measurement International Consortium. (2011). Guideline for the use of COSMIC FSM to manage Agile
projects version 1.0.
Cohn M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional, 1 edition.
Cohn, M. (2005). Agile Estimating and Planning, NJ: Prentice Hall, 1 edition.
Dumke, R. et al. (2008). Effort estimation for Agile Software Development Projects. 5th Software Measurement European Forum.
Ergun, A. N., & Gencel, C. (2007). Utilizing Functional Size Measurement Methods for Embedded Systems. Software Productivity
Analysis and Cost Estimation.
Felhman, T., & Santillo, L. (2010). From Story Points to COSMIC Function Points in Agile Software Development–A Six Sigma
perspective. International Workshop on Software Measurement–IWSM.
Foss, T. et al. (2001). A comparison of LAD and OLS Regression for Effort Prediction of Software Projects. Proc. 12th European
Software Control and Metrics Conference, pp. 9-15.
Gencel, C. & Demirors, O. (2008). Functional Size Measurement Revisited. ACM TOSEM, Vol.17, No.3, pp.71-106.
Jorgensen, M., & Shepperd M. (2007). A Systematic Review of Software Development Cost Estimation Studies. IEEE Trans. Softw.
Eng., vol. 33, no. 1, pp. 33–53.
Jørgensen, M. (2004a). A review of studies on expert estimation of software development effort. Journal of Systems and Software,
Volume 70 (1–2), pp. 37–60.
Jørgensen, M. (2004b). Top-Down and Bottom-Up Expert Estimation of Software Development Effort. Information and Software
Technology, 46, pp. 3-16.
McConnell, S. (2009). Software Estimation: Demystifying the Black Art: Demystifying the Black Art. O'Reilly Media, Inc.
57

Rowea G. & Wright G. (1999). The Delphi technique as a forecasting tool: issues and analysis. International Journal of Forecasting,
Volume 15, Issue 4, pp. 353–375.
Santana, C. et al. (2011). Using function points in agile projects. Agile Processes in Software Engineering and Extreme
Programming, pp. 176-191.
Popović, J., & Bojić, D. (2012). A comparative evaluation of effort estimation methods in the software life cycle. Computer Science
and Information Systems, 9(1), pp. 455-484.
Santillo L. (2012). Easy Function Points -- Smart Approximation Technique for the IFPUG and COSMIC Methods Assisi. 2012 Joint
Conference of the 22nd International Workshop on Software Measurement and the 2012 Seventh International Conference on
Software Process and Product Measurement
Stamelos, I. & Angelis, L. (2001). Managing Uncertainty in Project Portfolio Cost Estimation. Information and Software Technology,
43,pp. 759-768.
Trudel, S., & Buglione, L. (2010). Guideline for sizing Agile projects with COSMIC. International Workshop on Software
Measurement–IWSM.
58

Appendix A: Project Proposal for MSc in Information Systems and Technology
Name: Gediminas Siuskus
E-mail address: gsiuskus@gmail.com
Contact Phone: +44 7984 176571
Project Title: Effort Estimation in Agile Development based on User Stories
Supervisor: Cristina Gacek
Introduction
Effort prediction is one of the major topics in software development [1]. For every software development project it is important to
know how much it will cost. The estimated effort is needed at the early stage of the development in order to evaluate economic
feasibility and return on investment[2]. This makes estimating more complex task.
The estimation techniques and models help to construct the early estimates. To date most of estimating techniques built are based
on algorithmic models such as COCOMO and Functional Points [3], which were built for traditional waterfall development approach.
Moreover they are not applicable for agile software development methodology where there is a lot of uncertainty and requirements
are not specified in great detail. Techniques mostly used to estimate agile development projects are expertise-based, where the
developers estimate tasks and projects based on their past development experiences [3, 10]. These methods are criticized for their
bias and scholars are suggesting incorporating algorithmic approaches that solidify subjective developers’ evaluations [5].
One group of researchers have proposed a method based on automatically extracted predictors from the user stories, which form
59

integral part of agile methodologies [8]. A user story is user’s requirement specification in own words how the software should be
used. Automatic predictors are extracted from user stories for the effort prediction model. This approach suits well the principles of
agile development where effort of each iteration is predicted by developers from user stories. Also it tackles the problem of available
predictors of the project and can be easily extracted from the stories without extra effort or interruption of agile team. Finally this
model can be applied in practice by agile teams in predicting requirement effort and prioritizing them. It can be used as independent
and objective tool to reduce the risk of over/under estimation and incorporating knowledge of historical predictions.
Aims, Objectives and Scope
This research aims to construct a quantitative prediction method for agile project effort estimation in the thorough case study of
Scrum in two industrial projects with the same outcome. Those projects involve different team of developers with almost alike
functionality and final product. The effort prediction study results are planned to be compared with the findings of the original paper
and subjective estimates made by developers during the “planning poker”.
The key objectives of the project are:
● conduct two case studies to investigate potential of prediction model;
● compare two alike projects estimates and model predictions;
● investigate possible improvements of the model.
Literature review
According to the academic studies in the field of effort prediction there were no algorithmic models developed for agile and iterative
processes recently [8, 9, 12]. The most popular method for predicting effort in agile projects is expert estimation, where engineers
estimate development requirements themselves [3, 13]. This method is easily applicable to the small agile teams. Nevertheless
expert estimates are subjective and might be highly biased [14].
60

A founding member of the Scrum Alliance Mike Cohn in his book proposes several ideas about iterative project estimation and
planning [13]. However the practical application of these ideas in software development is not presented.
Moser et al. in their latest studies propose two different methodologies predicting effort for agile development. In 2007 study
prediction model is based on object oriented design metrics [8] and 2011 study - on predictors automatically extracted from user
stories[9]. 2007 model delivered 30% magnitude of relative error - MER (common criteria for evaluation of cost estimation model)
relying strongly on the assumption that informal design documents provide accurate design metrics. Without the assumption, model
performance was meager. Much simpler model of 2011 resulted in MER of 38% with more advantages over the 2007 study. Firstly
the model fits well with traditional agile planning activities before starting a new development sprint. Secondly there is no need to
estimate design or size metrics at the beginning of the project. And thirdly the accuracy of the model is equal and sometimes even
better than subjective experts’ estimates. Due to these reasons I have chosen the latter methodology for comprehensive case study
of Scrum, an iterative and incremental agile software development framework, in two industrial projects.
Methodology
The effort prediction model build up is divided in two stages depicted below. In the first stage effort predictors are extracted from a set
of completed user stories:
1. Keywords - the most frequent terms from the user stories; model will be tested out to find out the optimal number of keywords
to investigate and they will form binary values with 0 - not present and 1 - present in the selected user story;
2. Priorities: every user story has a priority, which indicates importance of it to the customer; user story priority affects the
development effort; top priority has assigned number one;
3. Number of characters - are calculated for each user story from their descriptions; user stories with longer descriptions written
by developers indicate longer development effort.
The extracted predictor data from the user stories will be used in regression analysis (simple and support vector) to construct
prediction model. Regression is chosen as the most popular approach to investigate effort prediction [3] and most used to construct
61

automatic models from the quantitative data [8].
Figure 1. Effort prediction model construction (stage 1)
In the second stage of the analysis the new user stories will be applied to the model constructed in the first stage. The model
predictions will be validated using leave one out (LOOV) cross validation procedure. Magnitude of Relative Error (MRE) and
Magnitude of Error Relative to the estimate (MER) will be calculated to evaluate the model. They are most common [3] evaluation
criteria for software development effort prediction.
Figure 2. Effort prediction model operation (stage 2)
Finally, predicted results will be compared among the selected industry cases, developers’ estimates and findings by Abrahamsson
62

et al to draw final conclusions.
Proposed methodology might have some limitations in this study. The dataset of two similar selected agile projects is limited and can
affect robustness of statistical conclusions. Further low number of predictor variables and too simple model can be not enough to
draw valid conclusions.
Work Plan
The table below presents all the major project tasks and milestones. Every deliverable in the project will be evaluated with the help of
the project supervisor in order to deliver quality and keep focus on the goal. This is the initial plan, which will be updated constantly
depending on the circumstances and overall progress. Moreover this schedule does include buffers for the time-based risks that are
associated with the project.
Risks
The greatest risk of the project is robust data as only two projects have been selected with approximately 30 user stories per each.
Therefore more time is given for data collection and processing task in order to find back up data if needed.
The second risk is comprehension of statistical calculations. The proposed model has number of statistical tests that i have never
used before. Thus theoretical knowledge and practical skills in using them pose a big risk. My plan is to consult supervisor and and
other scholar having great knowledge of these statistical methods.
63

The final risk is time management. The work plan above can change at the early stage of data processing and statistical analysis if
initial findings will be invalid. To address this risk i am planning to start research early and change the plan if needed accordingly.
64

References
[1] M. Jorgensen and M. Shepperd, “A Systematic Review of Software Development Cost Estimation Studies,” IEEE Trans. Softw.
Eng., vol. 33, no. 1, pp. 33–53, Jan. 2007.
[2] C. F. Kemerer, “An empirical validation of software cost estimation models,” Commun. ACM, vol. 30, no. 5, pp. 416–429, May
1987.
[3] M. Jørgensen, “A review of studies on expert estimation of software development effort,” J. Syst. Softw., vol. 70, no. 1–2, pp.
37–60, Feb. 2004.
[4] M. Shepperd and C. Schofield, “Estimating Software Project Effort Using Analogies,” IEEE Trans. Softw. Eng., vol. 23, no. 11, pp.
736–743, Nov. 1997.
[5] A. Trendowicz, J. Heidrich, J. Münch, Y. Ishigai, K. Yokoyama, and N. Kikuchi, “Development of a hybrid cost estimation model in
an iterative manner,” in Proceedings of the 28th international conference on Software engineering, New York, NY, USA, 2006, pp.
331–340.
[6] R. E. Gallardo-Valencia, V. Olivera, and S. E. Sim, “Are Use Cases Beneficial for Developers Using Agile Requirements?,” in Fifth
International Workshop on Comparative Evaluation in Requirements Engineering, 2007. CERE ’07, 2007, pp. 11–22.
[7] P. Abrahamsson, R. Moser, W. Pedrycz, A. Sillitti, and G. Succi, “Effort Prediction in Iterative Software Development Processes –
Incremental Versus Global Prediction Models,” in First International Symposium on Empirical Software Engineering and
Measurement, 2007. ESEM 2007, 2007, pp. 344–353.
66

[8] P. Abrahamsson, I. Fronza, R. Moser, J. Vlasenko, and W. Pedrycz, “Predicting Development Effort from User Stories,” in 2011
International Symposium on Empirical Software Engineering and Measurement (ESEM), 2011, pp. 400–403.
[9] R. Moser, W. Pedrycz, and G. Succi, “Incremental effort prediction models in Agile Development using Radial Basis Functions,”
presented at the International Conference on Software Engineering & Knowledge Engineering, 2007, pp. 519–522.
[10] CESCHI, M., SILLITTI, A., SUCCI, G. & DE PANFILIS, S.(2005) “Project Management in Plan Based and Agile Companies.”
IEEE Software, 22, 21-25.
[11] M. Cohn, “User stories applied: for agile software development.” Addison-Wesley Professional, 2004.
[12] M. Alshayeb, W. Li, “An Empirical Validation of Object-Oriented Metrics in Two Different Iterative Software Processes”, IEEE
Transactions on Software Engineering, November 2003, 29(11): 1043-1048.
[13] M. Cohn, “Agile Estimating and Planning” Prentice Hall, 1 edition, November 2005.
[14] N.C. Haugen, “An Empirical Study of Using Planning Poker for User Story Estimation, “ AGILE 2006 Conference, 2006m, pp.
23-34
[15] Y. Matsuo and M. Ishizuka,“Keyword Extraction from a Single Document using Word Co-occurrence Statistical Information,“
International Journal on Artificial Intelligence Tools, 13, 2004, pp. 157-169
67

Appendix B: Historical sample COSMIC sizing
#
User story
Functional
process
Triggering
event
Sub-process description Data Group
Data
movemen
t type
CFP
CF
P
tota
l
Estimate Logged
1
As a user, I would like
to get RSS notifications
of my keyword
searches in order to be
updated.
Create
search
RSS feed
Actor types
a phrase in
the search
Actor types phrase in the
search
System Entry 1 5 10 20
Read article index SOLR search Exit 1
Present search results System Entry 1
Request RSS System Read 1
Display error message Messages Exit 1
2
As a TW sales person, I
only want users with
ARCHIVE subscription
to access archive
articles.
Restrict
archive
access
Actor
clicks/enters
article URL
Actor enters archive URL System Entry 1 5 9 10.5
Check if user is
authenticated
System Read 1
Check if user is
authorized
System Read 1
Display archive content News content Exit 1
3
As ad sales I want to
search for articles by
categories, so that I can
find out find out how
many stories are written
in a given period.
Search
archive by
tags
Actor types
a phrase in
the search
search
System Entry 1 4 4 6
Read article index SOLR search Exit 1
Present search results System Entry 1
69

4
As a TW editorial, I
want the newsletter to
be automatically sent
Send
newsletter
Newsletter
client
requests
XML
XML request System Entry 1 5 2 3.5
User validation System Read 1
Grab the latest posts System Write 1
Dispatch content to
newsletter client
System Exit 1
5
As a user, I want more
information before
signing up for a
subscription
Page
redirect
Actor enters
URL
Actor requests article
URL
System Entry 1 3 0.5 0.5
Check client cookies System Read
Deliver subscription page System Exit 1
6
As a user I want to
search for exact
phrases and get search
tips
Search
content
Actor types
a phrase in
the search
search
System Entry 1 3 2 1.5
Search result filtering
presented
SOLR search Read 1
7
As a journalist, I would
like to make picture
galleries
Create a
gallery
Journalist
creates
picture
gallery
article
Journalist creates picture
gallery article
CMS Entry 1 10 18 13.5
Journalist requests
images CMS Read 1
The system displays the
requested data CMS Read 1
Journalist selects images CMS Write 1
Enter metadata CMS Write 1
Arrange items' order CMS Write 1
When all information is
complete, journalist CMS Write 1
70

selects 'Save'
The system publishes
article Escenic Write 1
Article gets indexed into
search
SOLR Write 1
8
As a TW admin, I want
to be able to add
subscribers to the fleet
newsletters
Signup to
newsletter
Administrat
or selects
"add
subscriber"
Registrant enters
subscriber data
Subscriber
data
Entry 1 4 4 6
The system validates the
data and checks if a
subscriber is unique
Subscriber
data
Read 1
The system creates a
new newsletter
subscriber
Subscriber
data
Entry 1
9
As a Journalist I want to
export the hardcopy
version to news website
Publish
epaper
Journalist
initiates
hardcopy
export
Journalist initiates export DTI Enter 1 3 3 3
System verifies export Escenic Read 1
1
0
As a user, I want logical
messages *WHEN
TRYING TO ENTER
AN ARTICLE OLDER
THAN 14 DAYS*
Access
archive
article
Administrat
or selects
"add
subscriber"
Actor enters archive URL System Entry 1 6 4 9.5
Check if user is
authenticated
System Read 1
Check URL type System Read 1
Check if user has access
to this type of article
System Read 1
Display content News content Exit 1
1
1
As a search engine, I
want to find pages
Optimize
content
Search
engine bot
Search bot sends request Escenic Entry 1 3 7 2
71

Improving Effort Estimation in Agile Software Development Projects

Improving Effort Estimation in Agile Software Development Projects

Recommended

Recommended

More Related Content

Similar to Improving Effort Estimation in Agile Software Development Projects

Similar to Improving Effort Estimation in Agile Software Development Projects (20)

Recently uploaded

Recently uploaded (20)

Improving Effort Estimation in Agile Software Development Projects