It'll Take Two Weeks

Transcript

1. WHY SOFTWARE ESTIMATES ARE A PIPE DREAM Ines Panker | March 2026 IT'LL TAKE TWO WEEKS
2. You will never be able to accurately estimate the time and effort it will take to build a piece of software ... for as long as you keep building new things.
3. It doesn't have to be accurate, just give me a number.
4. Predictions of future effort Predictions of future effort are always based on the are always based on the facts of past effort. facts of past effort.
5. It has been known since the It has been known since the 70s that developers tend to 70s that developers tend to give very optimistic give very optimistic estimations. estimations.
6. “We investigated more than 100 projects from 6 development organizations and found that about 30% of the projects had applied effort prediction intervals on the activity level. However, only 3 of these projects had logged the actual effort applying the same work break-down structure as used when estimating the effort. In fact, even these three projects had to split and combine some of the logged effort data to enable an analysis of the accuracy of the effort of PIs. (tn: PI = prediction interval, a minimum - maximum effort).” M. Jørgensen, K. Teigen, K. J. Moløkken-Østvold Better Sure Than Safe? Overconfidence in Judgment Based Software Development Effort Prediction Intervals
7. estimate=1240h actual=2400h actual=2400h 200% 1100h 1500h 1550h 1339h 2251h
8. average % of 2400h Developers 660h 28% Project Managers 960h 40% Designers 1260h 53% Customer Success 1550h 65% M. Jørgensen, K. Teigen, K. J. Moløkken-Østvold Better Sure Than Safe? Overconfidence in Judgment Based Software Development Effort Prediction Intervals
9. “As a result, technical background did not lead to better effort PIs, only to more confidence in the estimates. This is in line with the distinction between an “inside” versus an “outside” view in predictions (Kahneman and Lovallo 1993).” M. Jørgensen, K. Teigen, K. J. Moløkken-Østvold Better Sure Than Safe? Overconfidence in Judgment Based Software Development Effort Prediction Intervals
10. “An inside view forecast is generated by focusing on the case at hand, by considering the plan and the obstacles to its completion, by constructing scenarios of future progress, and by extrapolating current trends. The outside view is the one that the curriculum expert was encouraged to adopt. It essentially ignores the details of the case at hand, and involves no attempt at detailed forecasting of the future history of the project. Instead, it focuses on the statistics of a class of cases chosen to be similar in relevant respects to the present one.” Kahneman and Lovallo Timid Choices and Bold Forecasts: A Cognitive Perspective on Risk Taking
12. Group LESS Group MORE Experiment A 160h 150h Experiment B 120h 80h Experiment C 316h 200h Experiment D (project managers) 55% success rate 70% suceess rate M. Jørgensen Identification of More Risks Can Lead to Increased Over-Optimism of and Over-Confidence in Software Development Effort Estimates
13. What is a useless estim ate?
14. Developers admitted that they believe their managers will see them as less competent if they provide estimates with huge margins. Dev 2 Dev 1 Better to be precise than accurate
16. MATH neural networks case-based reasoning fuzzy logic modeling simulation based probability regression- based approaches classification and regression trees Bayesian statistics lexical analyses of requirement specifications
17. N Na at tu ur re e N Na a t tu ur re e N Na at tu ur re e
18. We’ve tackled this before, we’ve timed it, we can guesstimate the effort like seasoned pros!
19. Input Parameters
20. “For predictive measurement the model (tn: =metric) alone is not sufficient. Additionally, we need to define the procedures for a) determining model parameters and b) interpreting the results. The model, together with procedures (a) and (b), is called a prediction system. Using the same model will generally yield different results if we use different prediction procedures.“ N. Fenton Software Measurement: A Necessary Scientific Basis
21. “.. size is defined as the number of delivered source statements (tn: LOC), which is an attribute of the final implemented system. Since the prediction system is used at the specification phase, we have to predict the product attribute size in order to plug it into the model. This means that we are replacing one difficult prediction problem (effort prediction) with another prediction problem which may be no easier (size prediction)” N. Fenton Software Measurement: A Necessary Scientific Basis
22. “Today, almost no model can estimate the cost of software with a high degree of accuracy. ... To improve the algorithmic models, there is a great need for the industry to collect project data on a wider scale.” Hareton Leung Software Cost Estimation
23. “The proportion of estimation studies where estimation methods are studied or evaluated in real-life situations is low. We could not, for example, find a single study on how software companies actually use formal estimation models. Our knowledge of the performance of formal estimation models is, therefore, limited to laboratory settings” M.Jørgensen and M.J.Shepperd A Systematic Review of Software Development Cost Estimation Studies
24. the size and complexity of the project the size and complexity of the project the resources provided to the project the resources provided to the project Searching: a human or AI oracle Searching: a human or AI oracle
25. As you do the same thing again and again, you get better and faster at it. But then the world changes and that makes you slow again.
26. Why are people even asking this question: “How long will it take to create this piece of software”? “What can you build for this much money”?
28. Let ’s build it iterativ ely CORE OPTIONAL CORE OPTIONAL CORE OPTIONAL CORE OPTIONAL
29. wonky - 15.7 days = ?
30. We don’t know how long this will take. But here is a list of things we will gain and here is a list of risks we will take.
31. There is no point in giving estimations that you can’t stick to with a reasonable error margin.
33. Cost escalation → Probability → 0% 50% 100% 200% 400% ... Normal distribution Power-law distribution extreme events keep happening drops to ~zero 4,677 IT projects | 66 countries
34. 4,677 IT projects MOST PROJECTS Median ~0% overrun AVERAGE Mean 80% overrun WORST CASE 28,000% overrun
35. Incorrectly assuming a normal (Gaussian) or near-normal distribution for cost risk increases organizations’ exposure to such risk by severely underestimating the probability of large cost overruns. Flyvbjerg et al. The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution
37. Maybe it is time we stop Maybe it is time we stop estimating tasks left and right estimating tasks left and right and instead start managing the and instead start managing the project’s risk and customer’s project’s risk and customer’s expectations. expectations.
38. Links to all sources Ines Panker | March 2026