Project Effort Estimation Methodologies
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 flavors:
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.
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 quantitative and qualitative weighted characteristics and produces effort estimation.
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 (over fitting).
-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.
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 flavors:
- 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.
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 quantitative and qualitative weighted characteristics and produces effort estimation.
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 (over fitting).
-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.
Comments
Post a Comment