Cost Estimation and Budget Techniques for Scrum Practices
Abstract—The expansion of software services and global con-
nectivity has pushed the requirements for software deve-
lopment projects. This new level of demands can lead to
changes in the scope and deliverables of the project, causing
a direct impact on the budget and time tables. The use of
newer methodologies for software development, referred as
Agile methodologies, like the case of Scrum, focuses on the
development team to provide the functionality in the stipulated
time, but can suffer from increases in the overall budget. Scrum
attempts to increase productivity and speed, taking under
consideration changes in the project’s scope and deliverables
through iterations, providing adaptability and flexibility to
the project, but if not properly controlled, the cost of the
project can increase, which is one of the reasons of why many
projects using Scrum fail. In this paper we propose a new
method that supports Scrum practices, but limits its operation
through the estimation of what is to be invested in the product.
Using this budget estimation, based on the necessary efforts
to complete the functionalities, minimizes the risk associated
with inadequate budget management.
Index Terms—Scrum; Agile; cost estimation; budget; Line of
Code; LOC; FP;
1. Introduction
In today’s world, software development has to overcome
new challenges that are part of modern requirements. This
has spawned newer methodologies for coping with this
demands, or so called agile methodologies. One of the
most important characteristics in agile methodologies, is the
ability to make changes along the software’s development
cycle. Although this can be seen as an advantage in project
management, it could cause problems if the appropriate
project management controls are not in place. According
to “The Chaos Report 2015” [1], 61% of software projects
using an agile methodology failed. This data shows that agile
methodologies still present problems in practice, many of
them related to budget and project costs.
Agile methodologies [2] are a set of good practices for
project management, which are used primarily for software
projects, but nowadays not limited to them. Agile methodo-
logies vary from traditional methodologies, like PMI’s PM-
BOK [3], [4], where they focus on people and interactions,
more than plan-oriented and activity centric like PMBOK.
Agile methodologies are based on the “Agile Manifesto”
[5], which is founded on a set of principles that are grouped
into four values:
• Individual and interactions over process and tools.
• Working software over comprehensive documenta-
tion.
• Customer collaboration over contract negotiations.
• Responding to change over following a plan.
The main objective of these methodologies is to
minimize the impact of tasks that are not critical to the
success of the project. Looking aimed at increasing the
efficiency of the project team.
Scrum, defined in the “SCRUM Development Process”
by Ken Shwaber [6], is one of the most popular agile
methodologies in the world. The word Scrum, is short for
“scrummage” used in the sport Rugby, where all players get
their heads close together to gain the ball possession. Analog
to the software development process, Scrum means that
highly productive and collaborative multidisciplinary teams
get together to move the project forward. Scrum is defined
as an iterative and incremental approach to software deve-
lopment, which model states a series of roles and practices
that specify the development process to be executed during
the project. The Scrum methodology will be explained in
more detail in Section 3.
In this work we study a problem that Scrum presents
where the lack of control in the project scope can impact the
overall budget. This problem can arise because the Product
Owner has too much power in Scrum (roles also defined
later), so he can decide which user story has the highest
priority. By doing this, he can change the approach for the
project in every sprint. Even though the Scrum Master can
guide the Product Owner to stay focus in the priority of the
user stories that help the business needs, the project can get
out of scope, mainly the budget.
This new approach for the Scrum methodology, adds
best practices to the management of costs and budgets.
We must create a budget plan to create some limits of the
number of changes between each sprint, reducing the risk
of project failure. In order to estimate a budget, we must
limit the product and establish a budget estimate required
for implementation, providing visibility to stakeholders of
the costs to be added when requesting a change in the final
product.
This paper is organized as follows. In Section 2 we dis-
cuss the related work done in the area. Section 3 details the
main values of Agile Methodologies and its most important
practices. Section 4 explains the cost estimation techniques.
Section ?? introduces our approach for costs, budget and
Scrum. Section 5 presents a comparative analysis between
our approach and the results obtained in a real world project.
And finally we conclude and give our perspective in Section
6.
2. Related Work
The literature shows that the use of Scrum and Agile
methodologies can have an impact on costs and the overall
budget of the project. Many articles have raised the concern
about the risks of Agile methodologies in practice [1], [2],
[7], [8], [9], [10]. Kästner et al. [1] states that more than
half of software development projects failed, many of them
because due to inadequate project management controls.
The costs and budget management along the project can
easily become out of sight with Agile methodologies, partly
because these are based on people and tasks, providing
speed and many deliverables for stakeholders, which is only
a negative impact if they become out of budget scope.
D. Castilla [11] has made some insightful comparisons
for hybrid project management methodologies to overcome
challenges that today’s projects are facing. In her disser-
tation we can find various mixes comparisons for Agile
methodologies with traditional ones. Some mixes include
The Rational Unified Process (RUP) [12] from IBM, or
Extreme Programming (XP) [13] with Scrum[6]. Also, as
Scrum itself, it manages costs with a unique methodology
called Earn Value Management (EVM) [5], which is a
popular method for measuring the performance of a project.
This functions by comparing the amount of work completed
with the actual amount in order to determine if the cost
and schedule performance is being executed according to
plan. From here the term has emerged AgileEVM [8], which
seeks to control costs during project implementation for
decision-making. A drawback to this approach is that has no
management plan for costs or budget creation. Furthermore,
the budget to some extent creates a cap for effort, which
helps keep track of how you’re using it, now on a project
where only the value on the go is calculated tends to fall
into scope creep, which is a risk in any project [14], where
the scope is infinite, this has several causes, which can range
from customer requirements are not well prioritized to lack
of morals of a Scrum Master suggesting changes to postpone
the final delivery software.
In this work we follow the example of mixing techniques
and methodologies and add best practices for cost and
budget management, which have not been studied in depth.
This will bring many benefits to the scientific community,
but most importantly to companies around the world.
3. Scrum Methodology
3.1. Scrum
Scrum is an iterative and incremental approach to soft-
ware development. The model defines a series of roles and
practices that specify the development process to be exe-
cuted during the project. These practices are recurrent and
partial instalments of the final product providing feedback to
the customer on a regular basis. Also, due to this feedback
from the customer, he can make changes to the outcome of
the project, based on his needs, leading to a more accurate
final product. From a software development point of view,
this provides a flexible process, where deliverables can be
prioritized and even have a functional product before the
ending of the project.
The Scrum methodology specifies the following devices
and practices [8]. The term “Sprint”, is defined as the
period of time that the development of functionalities will
take. This duration is established by the team, based on
their experience and estimates. Sprint times may vary from
project to project, but usually are further catogorized in
short Sprints (1 to 2 weeks) and long Sprints (3 to 4 weeks).
The Scrum methodology defines the following roles:
• Product Owner: Represents the stakeholders or the
business side of the company and defines the func-
tions and priorities of the product.
• Scrum Master: Is usually an expert in Scrum and
acts as an advisor. It helps the team in the necessary
conditions to do their jobs. Also, ensures that the
methodology is implemented correctly.
• Team: Responsible for implementing the
functionality of the product.
Along with the previous roles, Scrum states the follow-
ing Artifacs:
• Product Backlog: List of features to implement.
• Sprint Backlog: List of features in development.
• Burndown Chart: Measuring progress of the team.
Scrum also defines “Ceremonies” [15] that need to be
implemented in every project:
• Sprint planning: The sprint planning meeting is
attended by product owner, ScrumMaster and the
entire Scrum team. During the meeting the product
owner describes the highest priority features to the
team. The team asks enough questions that can turn
a high level user story of the product backlog into
more a detailed task of the sprint backlog.
• Daily Scrum: For every day during a sprint, the
team holds the daily scrum meeting. This meeting
typically is held in the same location, at the same
time. Is recommended to be held during the morning,
as it would help to set the context for the coming day
work. These scrum meetings are strictly time-boxed
to 15 minutes.
• Sprint Review: At the end of each sprint, a sprint
review is held. During this meeting, the Scrum team
shows what they what they accomplished during
the sprint. Typically this takes the form of a demo
showing the new features of the overall project.
 • Retrospective meeting: In this Scrum ceremony, the
entire team participates dedicating period at the end
of each sprint to deliberately brainstorm on what
things are working and what don’t. Many teams do
this meeting immediately after the sprint review.
4. Cost and effort estimation techniques
The following estimation techniques are a way to solve
complex problems to be considered as a single task [16].
For this reason we decompose the problem making a series
of smaller tasks.
4.1. Lines of Code and Function Points
The data of Lines of Code (LOC) and Function Points
(FP) are used in two ways for an estimation in a project
[17], [9]: i.) Variable estimation: Used to calibrate each
element of software. And ii:) Base metrics: These metrics
are collected from previous projects and used in conjunction
with the estimated variables to develop cost and effort
projections. Although the previous techniques are different,
they do have some common characteristics.
The overall process for the of the LOC and FP tech-
niques begins when a project planner defines a declaration
which restricts the software scope and, from the statement,
tries to break it into smaller sub-functions, that can be
estimated individually. Then, it is estimated the LOC or
FP for each sub-function. Once each sub-function has their
LOC or FP, the base metrics are applied to the productivity
variables and to the appropriate estimation variables which
derives the cost and effort for the sub-function. Combining
the functions estimates, we get the total estimate for the
entire project.
As mentioned before, LOC and FP and different, ba-
sically in the level of detail required for the decomposi-
tion. When LOC is used as variable estimation, functional
decomposition is absolutely essential and often takes up
considerable levels of detail. Because the data required to
estimate Function Points are more macroscopic, the level of
the decomposition obtained when FP is used, the estimate
is considerably less detailed. Also, it should be noted, that
while LOC is estimated directly, FP is estimated indirectly
by the number of inputs, outputs, data files, and external
interface requests, among others.
Regardless of the variable estimate used, the project
planner typically provides a range of values for each de-
composed function. These are taken from historical data,
or when there are no comparisons available, the intuition
and experience from the project planner are used. Also,
the planner estimates the optimistic, most probable and
pessimistic values LOC or FP for each function. When a
range of values are specified, it is implied the degree of
uncertainty or the project.
The estimated value of LOC or FP is calculated. The
expected estimate for the variable Et is obtained as a
weighted average of the LOC or optimum FP. It consists
of variables To (most likely), Tm (most optimistic) and Tp
most pessimistic estimates. This gives a greater credibility
compared to the best estimate and follows a beta probability
distribution.
To + 4Tm + Tp
Et = (1)
6
Where:
Et = Estimated time
To = The most likely time required
Tm = The most optimistic time required
Tp = The most pessimistic time required
4.2. Scrum with LOC/FP
Although there are books [18] about how best practices
can be combined with an agile methodology and easily as
they can be combined with traditional project management,
which adds value to the project management, as well as tools
that provide a better control various aspects of the projects,
then why not apply so contrary? This has slowly begun to
emerge and several methodologies have started to combine
forces to achieve a firmer project management. Here comes
the proposal to combine the management of the budget of
the traditional methodologies with Scrum to strengthen a
weakness and to control the iterations, we will combine the
decomposition methodology software estimate based on the
budget line of code method (LOC) [19] applied to project
management and implementation of Scrum.
VT = CLOC ∗ LOC (2)
where:
VT = Total value
CLOC = Cost line of code.
LOC = Lines of code
4.3. Advantages and Disadvantages
4.3.1. Advantages. Reduced project risk by limiting the
iterations of the project based on the limited budget and
a better control over the investment to have a basis of how
much money has been invested in the software and what
percentage of completion leads to get regarding the scope
established from the beginning of the project.
4.3.2. Disadvantages. Despite being a good practice, is not
without drawbacks. This process takes time and therefore
it reduces the agility to the project having to do a little
planning and estimation of project costs, this may also
reduce some of the flexibility of the changes to the project
being unable to adapt to drastic changes on the structure
software.

5. Case Study
5.1. Problem
As an example will be taken the development of a system
for Booking for a hotel which has branches around the
world, have online booking system, for calls and in person.
The system consists of 7 modules and was developed with
the Scrum methodology. The project was developed in C#
and lasted one year and a cost of $135,000.
5.2. Application
To verify the proposed solution in the formula 2, a
comparison of the final cost of the system was performed
Booking taking reference historical project data, Table 1
summarizes the recorded information.
Historical facts
Average productivity by similar 320 LOC/pm
projects
Salary $1,200 monthly
Cost Line Of Cod (CLOC) $4.00
Project Cost $135,000.00
TABLE 1. H ISTORY INFORMATION SYSTEM FOR HOTEL .
To apply the method of line of code (LOC)
decomposition of software should be split in functions or
software modules which it is composed.
• Reservations module (MdRes).
• Accounting module (MdC).
• Reports Module (MdRep).
• Maintenance Module (MDM).
• User Module (MdU).
• Sales Module (MdV)..
• Administration Module (MdA).
After identifying the software modules must be esti-
mated should take the line of code. That can be done in
several ways, the best known is line of code (LOC). This
estimate can be done by expert opinion or the LDC method.
For this example we will estimate based on expert judgment,
because it is a common system. For this step we use the
PERT [6] method, formula 1 used to calculate the estimated
time.
With which estimates must calculate three line code;
the optimistic estimate is likely to have fewer lines of
code. With which estimates must calculate three line code;
optimistic, it ie the estimate may have fewer lines of code,
pessimistic, that is the estimate that has more lines of code
and most likely, that is the most likely have to be exact.
Table 2 MdS estimation module is as follows:
This method should be applied to other modules for esti-
mates of effort on each. Table 3 shows the results obtained.
LOC estimate of MdRep
Optimistic 4,600
Most likely 6,900
Pessimistic 8,600
TABLE 2. PERT ESTIMATION METHOD S ECURITY M ODULE
Module Estimate LOC
MdRes 2,300
MdC 5,300
MdRep 6,800
MDM 3,350
MdU 4,950
MdV 2,100
MdA 8,400
Total 33,200
TABLE 3. PERT ESTIMATE OF ALL SOFTWARE MODULES
Applying the formula 2 with the previously calculated
estimates the following is obtained:
TV = $4.00 ∗ 33, 200LOC
TV = $132, 800.00
We obtain as a result an estimated cost of $132,800,
when compared with the actual cost of the project to Table
1, the result is that the methodology is 97.8% accurate.
5.3. Discussion
In the example above took a software that was de-
veloped purely with Scrum, it was a successful project
which suffered several drastic changes on the structure and
priority modules repeatedly, is a typical Scrum project. In
the example a series of formulas, one with the LDC method
is a method of decomposition of software projects mainly
for cascading, which breaks down the lines of software
code with an estimate based on several variables applied
estimation efforts and then combined[3] with the method of
estimating tasks CPM PERT, which gives results in possible
scenarios of effort estimation (LDC) that can each module in
the system by averaging these results gives us a more likely
outcome which gave us $132,800 compared to $135,000 the
experiment shows that it is 97.8% accurate.
6. Conclusions and Future Work
With this method can support project managers to
implement a software system using Scrum, in order to
provide an estimated budget that the sponsor must invest
to implement a product or calculate a minimum project
budget to be met, of course estimation will not be one
hundred percent accurate, it depends on the contingencies
that may arise during implementation, but gives the project
manager a line cost base on which to stand and take this
as a reference for management to meet the objectives.
 Another work in the future will seek estimated by means
of rescheduling trying to establish a budget as changes are
requested in each Sprint, this mainly to make more precise
estimates of the project cost and suit the EVM for better
monitoring and control of the project. This analysis method-
ology for uncommon LCD systems can also be performed.

References
[1] C. Kästner, S. Apel, and M. Kuhlemann, “Granularity in software
product lines,” in Proceedings of the 30th international conference
on Software engineering. ACM, 2008, pp. 311–320.
[2] M. Jørgensen and K. Moløkken-Østvold, “How large are software
cost overruns? a review of the 1994 chaos report,” Information and
Software Technology, vol. 48, no. 4, pp. 297–301, 2006.
[3] W. R. Duncan, “A guide to the project management body of knowl-
edge,” "", 1996.
[4] D. J. Fernandez and J. D. Fernandez, “Agile project management—
agilism versus traditional approaches,” Journal of Computer Informa-
tion Systems, vol. 49, no. 2, pp. 10–17, 2008.
[5] M. Fowler and J. Highsmith, “The agile manifesto,” Software Deve-
lopment, vol. 9, no. 8, pp. 28–35, 2001.
[6] K. Schwaber, “Scrum development process,” in Business Object De-
sign and Implementation. Springer, 1997, pp. 117–134.
[7] N. ft n il Ionel, “Critical analysys of the scrum project management
methodology,” "", 2008.
[8] T. Sulaiman, B. Barton, and T. Blackburn, “Agileevm-earned value
management in scrum projects,” in Agile Conference, 2006. IEEE,
2006, pp. 10–pp.
[9] J. J. Dolado, “A study of the relationships among albrecht and mark
ii function points, lines of code 4gl and effort,” Journal of Systems
and Software, vol. 37, no. 2, pp. 161–173, 1997.
[10] K. Molokken and M. Jorgensen, “A review of software surveys on
software effort estimation,” in Empirical Software Engineering, 2003.
ISESE 2003. Proceedings. 2003 International Symposium on, Sept
2003, pp. 223–230.
[11] D. Castilla, “A hybrid approach using rup and scrum as a software
development strategy,” "", 2014.
[12] P. Kruchten, The rational unified process: an introduction. Addison-
Wesley Professional, 2004.
[13] K. Beck, Extreme programming explained: embrace change.
addison-wesley professional, 2000.
[14] C. Romero, Técnicas de programación y control de proyectos. Edi-
ciones Pirámide, 1997.
[15] S. Alliance, “Scrum ceremonies,” 2008.
[16] K. Moløkken and M. Jørgensen, “A review of software surveys on
software effort estimation,” in Empirical Software Engineering, 2003.
ISESE 2003. Proceedings. 2003 International Symposium on. IEEE,
2003, pp. 223–230.
[17] C. Jones, “Backfiring: Converting lines of code to function points,”
Computer, vol. 28, no. 11, pp. 87–88, 1995.
[18] J. Highsmith, Agile project management: creating innovative prod-
ucts. Pearson Education, 2009.
[19] S. Keaveney and K. Conboy, “Cost estimation in agile development
projects.” in ECIS, 2006, pp. 183–197.