My notes about "Software Estimation: Demystifying the Black Art".
Estimation is not transitional between developers.
66% of enterprise software projects have cost overruns.
17% of IT projects are so bad that they can kill a company.
McKinsey suggestions are:
Focus on managing strategy stakeholders and not on estimation and cost.
Focus on short sprints and rigorous quality check
Focus on building an effective team and align team with overall product goal
Estimate vs Not Estimate
In one Microsoft research was mentioned about 150% productivity increase after a decision "stop to estimation".
Software Estimation: Demystifying the Black Art:
Estimation and commitment are not the same.
Estimation and planning are different things. Estimation is an analytical process planning is goal seeking process.
Estimation can help to make a plan but not vice-versa.
Heisenberg’s Uncertainty Principle in the software development process observation and measurement is influent.
If the initial target and initial actual needs different on more than 20% then the manager cannot control the project (just imagine things and bag).
Do not make a range of your answer to narrow make sure that range wide enough that with 90% probability answer in range.
Software development industry is in big UNDERESTIMATE problem.
Cone of uncertainty represent cone in oxy coordinate and ox is project milestone. It becomes more and more narrow after each epoch.
The amount of functionality that several languages produce relative to the C programming language.
Language Level Relative to C
C 1 to 1
C# 1 to 2.5
C++ 1 to 2.5
Cobol 1 to 1.5
Fortran 1 to 2
Java 1 to 2.5
Macro Assembly 2 to 1
Perl 1 to 6
Smalltalk 1 to 6
SQL 1 to 10
Visual Basic 1 to 4.5
If you can count relative property you should do it, only if exact count impossible.
Try to avoid judgment and event blind judgment.
It is a question what to count? First of all counting process should not be expensive. And what to count depends on the project stage. On early stage business requirements available, project requirements. In a middle features, API. At the end lines of code, test cases.
Try to collect and keep historical data for future estimation.
Expert estimation. People estimate what they understand and not what actually involved in a task.
Use a checklist to not forgot details during estimation.
And treck progress collect historical data and do calculations.
Program evaluation and review technique.
Expected case = [BestCase + (4 x MostLikelyCase) +WorstCase] / 6
Magnitude Relative Error
MagnitudeRelativeError = AbsoluteValue (ActualResult - EstimatedResult) / ActualResult
"Productivity is an organizational attribute that cannot easily be varied from project to project" Putnam and Myers.
"Only 1% of projects have a clear start time date and 15% of projects have ambiguous end times" Capers Jones.
The estimate by decomposition principle, which is based on the big number theorem. Just break your task on small tasks and make an estimation. And make sure that subtasks estimation more the less accurate and errors present at both ends + and -.
Estimate new projects by comparing them to similar past projects. And possibly decompose the estimate into pieces. A project should be comparable (project size more the less similar, language, technology, team member).
If you cannot make straightforward estimation in some units you can use proxy base estimation and make estimation in other units but relative units to original one.
Wideband Delphi estimation is good on early project stage when too many questions exist. For this type of estimation, you should involve several estimators with appropriate quality. And they should provide anonymous estimation with the next discussion. This technique can decrease error on 40%, and the shift range of individual estimation and new group estimation will be more precise.
Documentation find/check/read/
Code grep/code size estimate/
Code build/get logs from code/
Outcome logs parsing/analisis
Feature coding
Commit patch/review/revert/
Estimation is not transitional between developers.
66% of enterprise software projects have cost overruns.
17% of IT projects are so bad that they can kill a company.
McKinsey suggestions are:
Focus on managing strategy stakeholders and not on estimation and cost.
Focus on short sprints and rigorous quality check
Focus on building an effective team and align team with overall product goal
Estimate vs Not Estimate
In one Microsoft research was mentioned about 150% productivity increase after a decision "stop to estimation".
Software Estimation: Demystifying the Black Art:
Estimation and commitment are not the same.
Estimation and planning are different things. Estimation is an analytical process planning is goal seeking process.
Estimation can help to make a plan but not vice-versa.
Heisenberg’s Uncertainty Principle in the software development process observation and measurement is influent.
If the initial target and initial actual needs different on more than 20% then the manager cannot control the project (just imagine things and bag).
Do not make a range of your answer to narrow make sure that range wide enough that with 90% probability answer in range.
Software development industry is in big UNDERESTIMATE problem.
Cone of uncertainty represent cone in oxy coordinate and ox is project milestone. It becomes more and more narrow after each epoch.
The amount of functionality that several languages produce relative to the C programming language.
Language Level Relative to C
C 1 to 1
C# 1 to 2.5
C++ 1 to 2.5
Cobol 1 to 1.5
Fortran 1 to 2
Java 1 to 2.5
Macro Assembly 2 to 1
Perl 1 to 6
Smalltalk 1 to 6
SQL 1 to 10
Visual Basic 1 to 4.5
Estimation tips:
If you can count exact value you should count exact value.If you can count relative property you should do it, only if exact count impossible.
Try to avoid judgment and event blind judgment.
It is a question what to count? First of all counting process should not be expensive. And what to count depends on the project stage. On early stage business requirements available, project requirements. In a middle features, API. At the end lines of code, test cases.
Try to collect and keep historical data for future estimation.
Expert estimation. People estimate what they understand and not what actually involved in a task.
Use a checklist to not forgot details during estimation.
And treck progress collect historical data and do calculations.
Program evaluation and review technique.
Expected case = [BestCase + (4 x MostLikelyCase) +WorstCase] / 6
Magnitude Relative Error
MagnitudeRelativeError = AbsoluteValue (ActualResult - EstimatedResult) / ActualResult
"Productivity is an organizational attribute that cannot easily be varied from project to project" Putnam and Myers.
"Only 1% of projects have a clear start time date and 15% of projects have ambiguous end times" Capers Jones.
The estimate by decomposition principle, which is based on the big number theorem. Just break your task on small tasks and make an estimation. And make sure that subtasks estimation more the less accurate and errors present at both ends + and -.
Estimate new projects by comparing them to similar past projects. And possibly decompose the estimate into pieces. A project should be comparable (project size more the less similar, language, technology, team member).
If you cannot make straightforward estimation in some units you can use proxy base estimation and make estimation in other units but relative units to original one.
Wideband Delphi estimation is good on early project stage when too many questions exist. For this type of estimation, you should involve several estimators with appropriate quality. And they should provide anonymous estimation with the next discussion. This technique can decrease error on 40%, and the shift range of individual estimation and new group estimation will be more precise.
Feature estimation list:
Keyword checkDocumentation find/check/read/
Code grep/code size estimate/
Code build/get logs from code/
Outcome logs parsing/analisis
Feature coding
Commit patch/review/revert/
