• Posted on: 8 August 2013
• By: spyrosktenas

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.

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”.
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 judgement. 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.

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.

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.

More 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.

First of all, I would recommend trying the free Orange Effort Estimation Tool

Orange Effort Estimation
The tool is web-based, therefore it can be used from anywhere with a web browser. There is a server part and a client side. All calculations and data are performed/stored in one central server/database. The client communicates using SOAP web services. The client side code is available, as open source, to everyone to download.

This tool enables software development effort estimation using 5 different methods. All industry standard methods are used.
COCOMO II, Work Breakdown Estimation, Analogy / Comparison Estimation, Custom modular estimation for WEB and Mobile

The tool can be feeded with custom modules estimations for use in future project estimations and, also, allow the feeding of data for analogy/comparison effort.
With you ID you can save and edit your estimations. It has a lot of comments for most fields in order to help you. The tool, based on data entered, may use all methods and give a combined estimation or use any combination, even just one of them to provide effort estimation.
In addition, some basic suggestions are available in case the actual effort is available to help for better effort estimation.

Learm more an get the tool at http://tecorange.com/orange-effort-estimation-tool-software-development

Effort Estimation Mobile Application

Effort Estimation Mobile Application can be used by sales people, developers, designers, project managers and actually anyone that can capture basic requirements. Its a tool that everyone should have.

It is available as a mobile application for all platforms (iOS, Android, Windows Phones and as Mobile Web App). Main features are:

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.
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.

For moving from effort to software costing read the Cost of Software article.

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.

“When the territory and the map disagree, believe the territory.” Swiss Army Manual