The document discusses the importance of effort estimation in software development, detailing its role in project planning and resource allocation. It highlights common estimation methods, their pros and cons, best practices, and common mistakes in the estimation process. Accuracy in effort estimation is crucial as it significantly affects project outcomes, with methods like Work Breakdown Structure and COCOMO II being emphasized alongside the need for experienced judgment.

1. Spyros Ktenas, BSc (IT), MBAEffort Estimation for Software Development
1
Effort Estimation for Software Development
Spyros Ktenas, BSc (IT), MBA
Software effort estimation has been an important issue for almost everyone in software
industry at some point. Below I will try to give some basic details on methods, best practices,
common mistakes and available tools.
Why is proper effort estimation important?
Effort estimation is essential for many people and different departments in an organization.
Also, it is needed at various points of a project lifecycle.
Presales teams need effort estimation in order to cost price custom software and project
managers need it in order to allocate resources and time plan a project.
Usually, software development is priced based on the person days, it requires in order to be
built, multiplied by a daily person day rate. Without effort estimation pricing is impossible.
Also, in order to plan a project and inform the project owners about deadlines and
milestones you have to know how much effort the job requires.
Finally, initial effort estimation shows if you have the resources to finish the project within
customer or project owner predefined time limits, based on your available man power.
Accuracy
Effort estimation accuracy depends on available information. Usually, you have less
information before you start the project (presales) and you have more information while
working in the project.
Most of the times, you can have more accurate effort estimation after requirement analysis.
However, initial effort estimation at early project stages is sometimes more important. E.g.
you give a financial offer based on early stage effort estimation. The price you will give will
probably bind you for the whole project, so it is important to have a good estimation from
the beginning.
Although it is obvious that accurate effort estimation is crucial, most of the times people fail
to predict well. Actually it is amazing how often and how much effort estimation goes
wrong.
Approximately 40% of industry software projects that get cancelled are cancelled due to,
partly or completely, failures in effort estimation.
It is a common fact that the larger the project is, the more essential is to have a good
estimation and, at the same time, the more difficult is to have one.
Have in mind that both low effort estimation and high effort estimation cause troubles, and
make the project take longer to complete.

2. Spyros Ktenas, BSc (IT), MBAEffort Estimation for Software Development
2
Who should do effort estimation and who is interested in it
Those responsible for effort estimations are usually the Project Managers. Depending on the
chosen effort estimation method, they can estimate alone or with expert advice from
developers, designers and testers.
Other people that need most the effort estimation are project owners and sales. Most of the
times, your effort estimation may be challenged by sales or management teams.
Sales people want low cost. This means low effort estimation; you want more resources and
your most valuable resource might be time. Also, you know that everyone will be happy if
you finish earlier and none if you finish later. In addition, developers and designers when
giving estimates have in their minds the possibility to be pressed to finish tasks in strict
deadline… and, for sure, they don't want the pressure, so, most commonly, they will take
the worst case when estimating.
So here is a conflict. How can you manage it? Well, there is no such thing as a global
solution. If you can come up with effort estimation of 100 person days and sales say that it is
too much, try to explain and break effort in small parts. In this way, people realize better the
work to be done. If they insist, try to find if you really have put too much of something, try to
see if there are things that can be done easier without losing specifications or requirements.
Finally, you can always say: “This is my estimate, but you can sell it as much as you want”.

3. Spyros Ktenas, BSc (IT), MBAEffort Estimation for Software Development
3
How you are effort estimating
There are a number of methods that are used for effort estimation. All of them have pros
and cons and all depend on the information the effort estimator has, his experience and his
judgment. Below I will explain most of these.
There are three main approaches for effort estimation:
Expert estimation: An expert on the subject of effort gives judgement on this.
Formal estimation model: Using a proper model you feed the system with proper data to get
some estimation.
Combination-based estimation: The estimation arrives with a mixture of both expert
estimation and formal estimation procedures.
Each approach has one or more methods. Below you will find the most common ones.
Work Break-Down Structure
This seems to be the most common method. Using this method you break down the project
to the small parts of works, tasks. Then, you estimate the effort for every task.
This is an Expert Judgement method and it comes with two flavours: Three Point System and
Delphic Oracle.
Using the Three Point method an expert gives 3 estimations for every task. Best Case, Most
Probable, Worst Case. The effort for every task is the outcome of a weighted average of the
three estimations where the most probable effort gets a higher weight.
Delphic Oracle means that we get 3 different people to estimate the task effort. The final
task effort is the average.

4. Spyros Ktenas, BSc (IT), MBAEffort Estimation for Software Development
4
Analogy / Comparison
It is a Formal Estimation Method. With this method we are searching for projects with
similar characteristics and we choose the closest to the one we are estimating.
Analogy based estimation is another technique for early life cycle macro-estimation. Analogy
based estimation involves selecting one or two completed projects that most closely match
the characteristics of your planned project. The chosen project is then used as the base for
your new estimate.
Comparison based estimation involves considering the attributes of the project to be
estimated, selecting projects with similar attributes and then using the median values for
effort, duration etc. from the selected group of projects to produce an estimate of project
effort.
A recent method is Weighted Micro Function Points (WMFP). It is a modern software sizing
algorithm invented by Logical Solutions. As many ancestor measurement methods use
source lines of code (SLOC) to measure software size, WMFP uses a parser to understand the
source code breaking it down into micro functions and derive several code complexity and
volume metrics.
COCOMO II
It is another Formal method that uses various parameters and a defined formula to estimate
effort (parametric model)
COnstructive COst MOdel II (COCOMO II) is the latest major extension to the original
COCOMO (COCOMO 81) model published in 1981.
COCOMO accepts as input quantative and qualitative weighted characteristics and produces
effort estimation.
Group Estimation (Wideband Delphi)
The Wideband Delphi estimation method is a consensus-based technique for estimating
effort. People in team meeting submit anonymous effort estimation forms and then discuss
the points where estimations vary a lot.
Estimating Size
Most formal methods require somehow defining project size. Most of them use SLOC (single
lines of code) or Unadjusted Function Points (e.g. database tables, input screens), while
expert judgement methods focus on breaking down the project to small part that are easy to
directly predict effort.
In order to use formal methods and since, especially at early stages, you don't know SLOCs,
you should use your experience on past projects and on a good analysis of the requirements.
If you keep estimating and then check the actual size with your initial estimate you will
become more and more accurate with project sizing.

5. Spyros Ktenas, BSc (IT), MBAEffort Estimation for Software Development
5
Best Practices for Effort Estimation
Below I have summarized some of the best practices someone should follow for better effort
estimation (at least what in my opinion should work better)
-If you use work break down structure, use both Three Point Estimation and Delphic oracle
and see what works better for your organization.
-Identify the right people to do estimations. Some may prove pessimistic while others very
optimistic.
-Use more than one methods and compare the results (assuming you have the time to do
so).
-Usually the people that will have to develop the project will be pessimistic.
-People that will not have to work on the project are most of the times optimistic.
-Keep all your estimates and compare them with actual results in order to calibrate your
models.
-Gather as much information about requirements as you can before you start estimation.
-Even if you have a requirements document, you may need to decompose the features into
smaller features that can be compared to past experiences.
-Do not get into very little/tiny details. The further you go at early stage estimation, the
more uncertainty will come and a less accurate estimation will arrive (overfitting).
-Don't put someone with no experience at all on this type of projects to estimate because
you will just take a WAG (Wild-Ass Guess) -estimation, and the hope of the estimator that he
is not wrong. Given the rarity of being punished for under-promising and over-delivering this
WAG tends to be a massive over-estimation.
-If sales and management have a strong opinion on your estimation, use their method. Price-
to-Win: Ask what price will get the customer and see what effort allows this to give to the
project. Break this effort to the tasks and see how feasible it is.
-Have in mind that the productivity falls as the project becomes bigger.
-Usually you need 20% of time for requirements, 25% for testing, 40% for design and 15% for
coding. If you spend more effort in one step, the most probable is that you need more effort
for all the rest based on their percentage in total project effort.
-Check if you can use group-based estimation that helps the entire team arrive at a shared
understanding of what each feature/story/etc. is supposed to do. This is also good in order
to keep a high bus factor.

6. Spyros Ktenas, BSc (IT), MBAEffort Estimation for Software Development
6
Common Mistakes
Steve McConnell, in “10 Deadly Sins of Software Estimation,” mentions 10 mistakes (sins) on
estimating scope. I will just mention all of these here although some already discussed.
1. Do Not Confuse estimates with targets
2. Do not say yes when really meaning no
3. Do not commit too early with lots of uncertainties
4. Do not assume underestimation has no impact on project result
5. Do not estimate in the “impossible zone“ (“Impossible zone” is a compressed schedule
with a zero chance of success)
6. Do not overestimate savings from new tools or methods (Payoff is less than expected)
7. Do not use only one estimation technique
8. Use estimation software
9. Include risk impact
10. Do not provide off-the-cuff estimates (treat estimation of a big project as a mini project)
Tools
There are many tools available to assist you with effort estimation.
You can even make your own excel spread sheets for counting effort using work break down
structure. But you can try first the tools available.
Agile COCOMO II
Agile COCOMO II is a web-based software cost estimation tool that enables you to adjust
your estimates by analogy through identifying the factors that will be changing and by how
much.
http://sunset.usc.edu/cse/pub/research/AgileCOCOMO/AgileCOCOMOII/Main.html
Bournemouth University - ANGEL Project
Estimation by analogy is the focus of a research project being undertaken by the Empirical
Software Engineering Research Group (ESERG) at Bournemouth University. A brief
bibliography and the downloadable ANGEL tool are provided.
http://dec.bmth.ac.uk/ESERG/ANGEL/
Costar and SystemStar
Costar is an automated implementation of COCOMO II developed by SoftStar Systems.
SystemStar, an automated implementation of COSYSMO.

7. Spyros Ktenas, BSc (IT), MBAEffort Estimation for Software Development
7
http://www.SoftstarSystems.com/
KnowledgePLAN
SPR KnowledgePLAN is a software tool designed to help plan software projects. With
KnowledgePLAN you can size your projects and then estimate work, resources, schedule and
defects. You can evaluate project strengths and weaknesses to determine their impact on
quality and productivity.
http://www.spr.com/spr-knowledgeplanr.html
SLIM
QSM's Software LIfecycle Management (SLIM) tools support decision making at each stage
of the software lifecycle: estimating, tracking, and benchmarking and metrics analysis. Each
tool is designed to deliver results, whether used as a standalone application or as part of
QSM's integrated suite of software metrics tools.
http://www.qsm.com/products.html
Epilogue
Effort estimation requires knowledge, experience and judgment, along with trial and error
that will fine tune your methods. This article is a high level introduction, every method
especially model methods use complicated formulas and calculations to predict. Also more
methods are available (e.g. Planning Poker, a game like method). Effort estimation is
essential and important, but should not be the most important thing, if accuracy in
estimation proves to be of HUGE importance and there is a lot of pressure around it, then it
might be a project that you should not undertake.
What is important is to find out what suits your organization and fine tune avoiding common
mistakes. If you keep failing revise, even if your expectations say no. Effort estimation is just
another plan, but real results will show you the way.
“ .” Swiss Army ManualWhen the territory and the map disagree, believe the territory