A Sprint-Point Based Estimation Technique
In Scrum
Rashmi Popli
Computer Engineering Department
YMCA University of Science & Technology
Faridabad, India
rashmimukhija@gmail.com
Abstract— In the last few years Agile methodologies appeared as
a reaction to traditional software development methodologies.
The Scrum is the widely used method of Agile. Most of the
software development organizations are using Scrum these days
but these are facing problems related to estimation of cost and
effort. It has been observed that the current estimation method
in Scrum mostly rely on historical data from past projects and
expert opinion but in absence of historical data and experts these
methods are not efficient. So there is need of an algorithmic
method, which can calculate cost and effort of the software
project. In this direction S.Bhalero, Maya Ingel [2] has
considered some project-related factors that calculate the cost as
well as effort of the project for a general Agile environment.
However, several other project as well as people related factors
may affect the Scrum environment. In this work an Algorithmic
estimation method is being proposed considering various factors
thereby estimating the more accurate release date, cost, effort
and duration for the project specifically for Scrum. The
effectiveness and feasibility of the proposed algorithm has been
shown by considering three cases in which different levels of
factors are taken and compared.
Keywords-Sprint-point;Scrum;,Scrum Estimation;Cost;Effort
I. INTRODUCTION
Scrum is an Agile mechanism for building software
products in an incremental and iterative manner. Scrum
divides a software project in several iterations called as Sprints
of approximately 24 weeks [1]. The goal of a Sprint is
typically to develop a potentially shippable product increment.
The Scrum process consists of three phases. A Sprint starts
with a Sprint planning meeting where a Sprint backlog is
created. The backlog contains Sprint backlog items describing
all the work required to achieve the Sprint goal [4, 5]. The
estimation of cost, effort, size and duration of a software
project in a sprint is a difficult task. The accurate estimations
of software are critical for both developer and customer.
Ignorance of estimation methods may cause serious effects
like exceeding the budget, not delivered on time, poor quality
and not right product. So estimation of software is important
that involves the
978-1-4673-5986-3/13/$31.00 ©2013 IEEE
98
Naresh Chauhan
Computer Engineering Department
YMCA University of Science & Technology
Faridabad,India
nareshchauhan19@yahoo.com
determination of effort (person-month), duration (in months)
and cost (in rupees). Moreover it becomes more complex
when requirements of the project are changed continuously.
There is a fundamental problem applying accurate estimation
and tracking due to the quality of baseline plan and unclear
project scope for scrum project due to volatile requirements.
In Scrum, the estimation is done by historical data from past
projects which are not efficient. However, there may be
various project related factors that may affect the project
estimation. Moreover, people related factors may also affect
the project development as per Agile principles. Therefore,
both project as well as people-related factor must be
considered while estimating in Scrum environment. Thus an
algorithmic method that quantifies various project and people
related factor has been proposed in this work.
In Section II currently used estimation technique for Scrum
is discussed. In Section III related work in field of Scrum
estimation is described and in Section IV problems related to
estimation in Scrum are discussed and Section V describes
proposed Sprint-points, factors and algorithm. In Section VI
feasibility of our algorithm is shown, Section VII contains the
Conclusion and future work.
II. SCRUM ESTIMATION METHOD
The process of estimation starts from the planning phase
and refined throughout the project. Scrum methods adopt the
practice of accepting last minute changes in the software
through gathering the requirements in iterative and
incremental manner [2, 3]. Two-level estimation in Scrum is
described below.
A. Two-Level Estimation in Scrum
Scrum provides for two levels of estimation; one for work
(Tasks) to be completed within the current Sprint and one for
more distant Product Backlog Items (PBIs) as shown in Figure
1. In Scrum, Product backog items is a list of the requirements
prioritized by the Product Owner. Typically, the lower the
PBI’s priority, the less precisely it is detailed [13]. PBIs are
therefore used to capture feature-oriented requirements and
specified in detail on-demand without spending much time in
upfront requirements analysis. Releases are scheduled and
tracked at the PBI-level because PBIs represent the goals of
the product or Release cycle. Teams commit to PBIs in Sprint
Planning without Task level decomposition.
Scrum provides for valuable long-range metrics such as:
Estimated product
Backlog (PBI)
PBI’s selected for one
sprint
Sprint
PBI marked done
Task with
estimates
Figure 1: Two-level estimation in scrum
• Velocity: The rate at which the team completes PBI effort on
a Sprint-by-Sprint basis.
• Rate of Change: The rate at which things are changing on
the Product Backlog due to new work being introduced or the
re-estimation of existing items. These two metrics can be used
to forecast a Release completion.
Task Estimates
While PBIs describe “what” is being built, Tasks serve to
detail “how” the PBI will be achieved. In other words, tasks
describe the Team’s implementation plan for the PBI. A
separate estimation scheme is appropriate because Tasks
describe granular work. In fact, Scrum recommends using
“ideal engineering hours” for Task-level estimates [14]. After
PBI and Sprint Backlog is prepared estimation is done form
the historical data from the previous projects or from the
expert opinion approach.
III. RELATED WORK
S.Bhalero, Maya Ingle [2] proposed an algorithm for cost
estimation by incorporating various factors with different
intensity levels. These factors include mainly project domain,
configuration, performance, complex processing, data
transaction, operation ease, multiple sites and security. But
various factors like communication skill, managerial skill, and
familiarity in team are missing.
Jamieson [8] pointed out a number of problems with
current estimation models in scrum. First, the procurer must
often allocate the budget without sufficiently understanding
the requirements. Thus, the budget often does not reflect the
true scope of the effort, resulting in heavy and costly change
management, budget over-runs, and delays. The most
established methods of estimating the cost of software
development require more data than is typically available to
the supplier bidding on a tender from the procurer, resulting in
2013 International Conference on Information Systems and Computer Networks
misunderstandings, inaccurate quotes, and frequently, an
adversarial relationship between the procurer’s contract
manager and the supplier.
Benediktsson [11] investigated the impact of software
development approach on the resulting product and its
attributes by comparing V-model (VM), evolutionary model
(EM), incremental model (IM), and extreme programming
(XP).His findings were that XP and Scrum method provides
more quality and productivity.
Williams et al. [7, 9] investigated the usage of a subset of
XP [5] practices at a group in IBM. The product developed at
IBM using XP was found to have significantly better pre-
release and post-release quality compared to an older release.
The teams using XP reported an improvement in productivity,
schedule, cost and effort estimation. In addition, customers
were more satisfied with the product developed using XP
because the teams delivered more than what the customers had
originally asked for.
Heemstra [10] surveyed 364 organizations and found that
only 51 used models to estimate effort and that the model
users made no better estimate than the non-model users. Also,
use of estimation models was no better than expert judgment.
Finnie and Wittig [11] applied artificial neural networks
(ANN) and case-based reasoning (CBR) to estimation of
effort. Using a data set from the Australian Software Metrics
Association, ANN was able to estimate development effort
within 25% of the actual effort in more than 75% of the
projects.
IV. PROBLEMS IN EXISTING SCRUM ESTIMATION METHODS
Based on the critical study of various research discussed
above, several problems are there in existing estimation and
tracking methods for scrum software developments.
The first problem is Effort Estimation. Estimations are
done in units of time while to estimate how much each team
member can spend effective time for sprint related work is
more important. The fact is that no one can sit at one place to
complete the job without attending meetings, lunch breaks,
unexpected breaks, checking emails and phone calls etc.
The second problem is Release Date Estimation. The
Release planning is the activity to calculate the actual release
date so that the final product is handed over into use for the
customer. In Scrum Estimation technique a release plan is
made but it doesn’t consider various factors like velocity, cost-
benefit ratio etc.
The third problem is that story-points cannot be easily
related to the time duration because story points represent the
amount of work and the velocity differs from team to team.
Thus, a cost metric that is related to the time duration is
needed.
99
 The fourth problem is that because a story point is a Hypothetical values of sprint-points
relative value, the total story point value can fluctuate with a S.No Unadjusted Value of Sprint-
Level
points
slight variation in the baseline story point. To set the base use
story, the agile team finds the simplest user story and 2. 6 2
determines story points of other user stories based on the 3. 1 1
baseline. If the baseline story point changes, other story points
also have to be changed. Thus, an absolute value like sprint B. Proposed Factors
point is needed rather than a relative In this section various project and people related factors
are being proposed that affects the sprint-points and thus
In Scrum environment, at the initial stage of a project, affects the cost, effort and duration of a software project. The
there is high uncertainty about various project attributes. The project and people-related factors are shown in Table II.
estimates produced at early stages are inaccurate, as the
accuracy depends highly on the amount of reliable information TABLE II. PROJECT AND PEOPLE RELATED FACTORS
available to the estimator. Scrum Estimation methods may
Related Factors
lead to the errors in case of inexperienced Agile team. S.No
Project-Related Factors People-Related Factors
Therefore, there is strong need of analyzing the factors hat
affect the estimation of the Agile project. 1 Type of Project Communication Skill

2 Quality Requirement Familiarity in Team

V. PROPOSED WORK
Hardware and Software
3 Managerial Skill
Requirement
A. Sprint-Point Based Estimation Framework for Agile
Software 4 Ease of Operation Security

When planning about first sprint, at least 80% of the
backlog items are estimated to build a reasonable project map.
These backlog items consist of user-stories grouped in sprints.
But user-stories based estimation is done using hours, days or
weeks which are also including other activities. When a team
member estimates that a given task can be completed within 8
hours it does not mean that he can complete the task in one
day. Because no one can sit in one place for the whole day. So
the concept of Sprint-point is proposed. A Sprint-point
basically calculates the effective time which a team member
spends in Sprint-related work in that iteration.
Effective time for Sprint Related work = Average work day
time - Time allocated for other activities.
For example Average work day time = 10 hours
Time Allocated for other activities = 5 hours
Emails and Phone: 1 Hrs
Lunch: 1 Hrs
Meetings: 2 Hrs
Bug fixes: 1 hrs
Available time for Sprint Related work = 5 hours
Thus, it is important to estimate how much each member is
actually involved in one Sprint related work. For calculating
sprint-points the user-stories are divided into tasks. After this,
complexity of tasks are judged and complexity levels are
decided. According to the complexity levels an adjusted
values of Sprint points is assigned as shown in Table 1.
TABLE I. HYPOTHETICAL VALUE OF SPRINT-POINTS
Hypothetical values of sprint-points
S.No Unadjusted Value of Sprint-
Level
points
1. 10 3 software which as a consequence increases the quality of the
5 Complexity Working Time
6 Data Transaction
Experience of Previous
Project
7 Multiple Site Technical Ability
a. people-project related factors
1) Project Related Factors: These factors are related to project
like complexity of project, type of project and quality
requirements etc. These are described as follows.
a) Type of Project: The type of the project affects the
cost, effort and duration of the project. The project can be of
web based application, construction, new project development,
information system, military project etc. Projects can
categorize based on unique characteristics of different types of
projects.
b) Quality Requirement: Project quality may be
characterized as functionality, reliability, usability, efficiency,
maintainability and portability. The outcome product should
develop in such manner that it meets the customer’s
requirements. These features of project increase the cost and
duration of the project.
c) Hardware and Software Reqirements: Hardware and
Software requirements are basic need for the development of
the project. All projects need certain hardware components or
other software resources to be present on a computer. These
prerequisites are known as system requirements and are often
used as a guideline as opposed to an absolute rule.
d) Ease of Operation: Operation ease means how is it
easy for user to use or operate the product. It may be in the
form of a batter GUI, to understand the functionality of the
product, minimum user input etc. It increases the usage of the
software as well as customer satisfaction. System design and

2013 International Conference on Information Systems and Computer Networks 100

architecture include numerous activities to provide maximum
operational ease to user which as a result increase the cost,
size and effort of the software project.
e) Complexity: Complexity refers that how complex is to
develop project. Technical complexity includes a number of
aspects such as numbers of technologies are involved, number
of technical interface. Management complexity includes
project staffing and management etc. Complexity is major
aspect in estimation of a project, as the complexity of the
project increase Cost, Size and duration of project also
increase.
f) Data Transaction: Data transaction refers to the
transfer of the data from one machine to another. Data can
access from other machine as per requirement. Data
transaction affects the estimation of the project, for example if
high data transaction required it necessitate high security. That
means high cost of the project.
g) Multiple Sites: Multiple sites means software or
project is developed on one workstation or it is developed on
different workstations or sites and integrated later. Big size
projects are broken in parts and developed at different sites
according to the availability of requirement to develop project.
If software runs on multiple sites or many team members work
together in distributed environment, cost of the software will
increase due to the cost of communication and coordination.
2) People Related Factors: People related factors are the
factors which are people or team oriented. These factors affect
the duration of the project and ultimately the cost of the
project. People related factors are described as follows:
a) Communication Skills: Communication is an
important part of life. Communication skills are essential in all
areas of life. People in organizations usually spend 75 percent
of their daily time on communication through writing, reading,
listening, speaking, inter-debate etc. Communication skills are
as important as technical skills in a team.If there is good
communication in team then it is easy to understand each
other.
b) Familiarity in team:Familiarity in team affects the
team performance, namely team errors, i.e. errors that occur in
the interactions of team members. It has been observed that
there is a U-shaped relationship between team familiarity and
team errors. Initially when familiarity in team member
increases it reduces team errors; but they increase if team
members become too familiar.
c) Managerial Skills: Management is a challenging job.
It requires certain skills to accomplish such a challenge.
Managerial skill is the ability to communicate with other
persons in the department or organizations and the ability to
understand their desire and persuade them to ones point of
view are human skills.
d) Security:Security may be considered as network
security, functional security, code security, documentation
security etc. based on customer requirements. At the time of
2013 International Conference on Information Systems and Computer Networks
project development life cycle security must be taken as
higher priority factor.
e) Technical Ability: The technical skill implies an
understanding of and proficiency in a specific kind of activity,
particularly one involving methods, processes, procedures, or
techniques. It involves specialized knowledge, analytical
ability within that specialty, and facility in the use of the tools
and techniques of the specific discipline. Technical skills
involve process or technique knowledge and proficiency in a
certain specialized field such as engineering, computer and
accounting.
f) Working Time:Working time is the period of time that
an individual spends at paid occupational labor. Unpaid labors
such as personal housework are not considered part of the
working week. The Working Time is defined ‘any period
during which the worker is working, at the employer's disposal
and carrying out his activities or duties, in accordance with
national laws or practice.
C. Proposed Algorithm
The proposed algorithm explains the various steps
involved in estimating a project in scrum environment.
• Identify the people and project related factors which
effects the sprint-points in Scrum environment where
P= {p1, p2,....pi...,p n } where 1< i <=n
• Identify the unadjusted value of Sprint-points related to
each level in scrum environment
where UVSP= {p1+ p2+…..+ pn}
where Li(1<=i<=3)
• Compute the estimated sprint points(ESP) as
ESP=BSP+0.1(UVSP)
where BSP is Baseline Sprint Points
• Assign Quality Rate (QR) and Time Rate (TR) to each
of the factor based on the project and team.
QR= {qr1,qr2,qr3,qr4} where quality rate vary
between 1 to 4
TR= {tr1,tr2,....,tri,.......tr4} where -4<=i<=4
• Compute the velocity from first iteration as
Velocity = ESP/sprint point completed
• Compute the Estimated time for the project
Estimated Time = ESP/Velocity
• Compute Time factor (TF) and Quality factor (QF)
using assigned values of QR and TR.
Estimated Time Factor (ETF) =∑ (TRi *Li)
Estimated Quality Factor (EQF) =∑ (QRi *Li)
101
 • Compute cost factor from above values for one
iteration as Compute Total Sprint
Estimated Cost Factor (ECF) = |ETF* EQF| Points in one sprint

• Compute total estimated cost for the project as

Cost = ECF* total no. of iteration Compute Velocity and
Estimated time for one
sprint
Sprint
• Compute Total Estimated effort(TEE) for the project
TEE = Velocity per iteration*ESP*TF
Compute Time factor Task with
and cost factor estimates
As an instance, all the factors with their proposed values are
shown in the Table III. The Quality Rate (QR) [9, 10], Time
Rate (TR) are assigned according to the type of the factor and Compute Total
its importance and level of the factor. Unadjusted value of Estimated Cost and
Effort
Sprint-points (UV) is given to each factor. After this, a
Quality factor (QF) and a Time factor (TF) is calculated by
Figure 2: Proposed estimation in scrum
multiplying the level of each factor to corresponding QR and
TR. VI. EVALUATIONS AND RESULTS
TABLE III. In this section the feasibility of our algorithm is shown by
calculating the estimated values of Sprint Point, Cost, Size and
Effort for a small project. We had considered three cases
wherein the level of the factors is changed, and shown that
Hypothetical Values of factors
S.N how changed value of factors affect the estimated values. Let
LEV UVS
sprint point is 30 and velocity is 5. Velocity is the number of
Type of factors QR TR sprint points developed in each iteration. The cases are
EL P
1. Type of Project 4 4 3 10 discussed as below:
2. Quality Requirement 4 3 3 10 A. Case 1
3.
Hardware and Software
4 3 3 10
In first case only three project-related factors are considered
Req. which are complexity, ease of operation and Quality. These
4. Ease Of Operation 4 2 2 6 factors are firstly taken at low level and then at high level and
then the estimated value of Sprint-points and cost are
5. Complexity 4 4 3 10
calculated according to the level of each factor. The Table IV
6. Data Transaction 3 -1 1 1 shows that if just the level of the factor is changed from low to
high then the cost of the project increases to double of its value.
7. Technical Ability 2 -1 1 1

8. Tool availability 3 -3 1 1
TABLE IV. CASE 1
9. Mutiple Site 4 2 2 6
Project Case 1
10. Communication Skill 4 -1 1 1 Related
Factor Low High
11. Familiarity in Team 3 -3 1 1 UVSP 14 41
12. Managerial Skill 4 -4 1 1 ESP 31.4 34.1
13. Security 2 -1 1 1 QF 23 47
14. Working Time 4 -1 1 1 TF 20 38
a. Hypothetical values of proposed factors
ECF 460 1786

TEE 3140 6479

D. Proposed Estimation diagram
a. project-related factors
The estimation diagram explains the various steps involved
in estimating a project in Scrum environment as shown in B. Case 2
figure 2. In this case only three people-related factors are considered
which are working time, communication skill and technical
ability. These factors are firstly taken at low level and then at
high level and then the estimated value of sprint-points and
cost are calculated according to the level of each factor. The
Table V shows that if just the level of the factor is changed

2013 International Conference on Information Systems and Computer Networks 102

from low to high then the cost as well as the effort of the effort. When level of project-related factors like ease of
project reduces to half of its value. operation, complexity, Quality or data transaction is changed
from low to high then the total software cost rises to double of
TABLE V. CASE 2 its value. The result also shows that when the people related
factors like familiarity in team, security, managerial skill or
communication skill are of high level then the cost of the
People Case 2
Related
project is reduced. As if technical ability is high then cost will
Factor Low High be reduced.
UVSP 14 41 By this method Cost, effort and duration of small and
medium size project can be calculated efficiently. In the future
ESP 31.4 34.1 the other factors which affect the estimation most can be
QF 21 41 added; thereby having makes the estimation more correct and
efficient and further release date of the software project in
TF 8 2 Agile environment can be calculated by considering these
ECF 168 82 factors.
TEE 1256 314
REFERENCES
a. people-related factors
[1] Cockburn, “Agile Software Development,” Pearson Education, Asia
Low Price Edition, 2007.
C. Case 3 [2] S. Bhalereo, Maya Ingle,” Incorporating Vital Factors In Agile
Estimation Through Algorithmic Methods”, International Journal of
In this case three people-related factors and three project- Computer Science and Applications Technomathematics Research
related factors are considered which are working time, Foundation Vol. 6, No. 1, pp. 85 – 97,2009
communication skill, technical ability, complexity, ease of [3] Mike Cohn, “Agile Estimating and Planning",Addison-Wesley,2005.
operation and quality. These factors are firstly taken at low [4] Mike Beedle “Agile Software Development with Scrum”, Ken
level and then at high level and then the estimated value of Schwaber, Prentice Hall, 2001, pp. 100-101
Sprint-points and cost are calculated according to the level of [5] Mike Beedle , Martine Devos ,Yonat Sharon ,Ken Schwaber, Jeff
each factor. The Table VI shows that if just the level of the Sutherland, “SCRUM: An extension pattern language for hyper
productive software development”, 2000.
factor is changed from low to high then the cost and effort of
[6] P. Abrahamsson, Koskela, J., "Extreme Programming: A Survey of
the project increases. Empirical Data from a Controlled Case Study", Proceedings of
International Symposium on Empirical Software Engineering, pp. 73-82,
2004.
TABLE VI. CASE 3
[7] L. Layman, L. Williams, and L. Cunningham, "Motivations and
Measurements in an Agile Case Study", Proceedings of ACM SIGSOFT
People Case 3 Foundation in Software Engineering Workshop Quantitative Techniques
Related for Software Agile Processes (QTE-SWAP), Newport Beach, CA, 2004.
Factor Low High [8] Jamieson, D., K. Vinsen, G. Callender, “Agile Procurement to Support
UVSP 14 41 Agile Software Development, Proceedings of the 35th IEEE
International Conference on Industrial Informatics,2005.
ESP 31.4 34.1 [9] L. Williams, W. Krebs, L. Layman, A. Antón, and P. Abrahamsson,
"Toward a Framework for Evaluating Extreme Programming",
QF 30 66 Proceedings of Empirical Assessment in Software Eng. (EASE),
Edinburgh, Scot., pp. 11-20, 2004.
TF 6 18
[10] F. J. Heemstra, “Software cost estimation”, Information and Software
ECF 180 1188 Technology, vol. 34, no.10, pp. 627-639, 1992
[11] O. Benediktsson, D. Dalcher, and H. Thorbergsson,“Comparison of
TEE 942 3069 Software Development Life Cycles: A Multiproject Experiment,” IEEE
a. people-project related factors Proceedings – Software,vol 153, 2006, pp. 87-101.
[12] G. R. Finnie, G. E. Wittig, “AI tools for software development effort
estimation”, Software Engineering and Education and Practice
VII.CONCLUSION AND FUTURE WORK Conference, IEEE Computer Society Press, pp. 346-353, 1996.
[13] Rashmi Popli, Naresh Chauhan,” Research Challenges of Agile
In this paper sprint points, project and people related Estimation” Journal of Intelligent Computing and Applications” (July-
factors are proposed that impact the estimation of the project. Dec 2012.
Estimated value of Sprint points highly depends on the value [14] Rashmi Popli, Naresh Chauhan,” “Scrum- An Agile Framework”,
of these factors. If the level of the factors is changed then it International Journal of Information Technology and Knowledge
Management (IJITKM) ISSN: 0973-4414", Vol-IV, Number-I, 20 Aug
will affect the unadjusted value of sprint-points which in turn 2010.
affects the value of total estimated cost and total estimated

2013 International Conference on Information Systems and Computer Networks 103