How to estimate software development time for a feature

Last updated: 2026-10-11

When estimating software development time, treat a developer’s “two weeks” as the most typical outcome, not a guaranteed delivery date. Across 10,266 recorded tasks, the median actual time matched the estimate. However, the average task took 36% longer than estimated, and more than one in ten took at least twice as long. Use the estimate as a planning target, but set customer deadlines with enough extra time to account for less predictable tasks.

Key facts

In this article

• What is an estimate, actually?
• Why do software estimates run late?
• What should you ask when someone says two weeks?
• What should you promise a customer instead?
• How do you estimate software development time so the next one is better?
• Where RocketDevs fits
• Conclusion: stop treating estimates as promises
• Frequently asked questions

What is an estimate, actually?

An estimate is a single number representing a range of possible outcomes. The problem is that the person providing it rarely explains which outcome that number represents. In research reported by Halkjelsvik and Jørgensen, developers were given the same task and instructions, then asked what their estimates meant. The results varied considerably: 37% said the estimate represented the effort required if nothing went wrong, 27% said it was the most likely effort, 5% said it was the median, 9% said it was a safe figure, and 22% did not know. These findings appear in Time Predictions.

That uncertainty matters because the person giving the estimate and the person receiving it may interpret the number differently. The same research notes that the meaning of an estimate is rarely stated by the person providing it or questioned by the person receiving it. A founder might hear a firm commitment to deliver in two weeks, while the developer intends it as a best-case scenario.

A better way to interpret estimates comes from actual project data. A public dataset contains 10,266 software development tasks from a company serving the Lloyd's of London insurance market. Each task includes the developer's original estimate and the hours actually recorded. The analysis found that estimates aligned almost exactly with the median outcome. As Jones and Cullum put it in their analysis of the SiP dataset, “The SipP estimates are on the 50% (green) line, with half of all task actuals greater/less than the estimate”. Our own analysis of the published SiP data confirms that the median ratio of actual to estimated hours is exactly 1.0.

In practical terms, when a developer estimates two weeks, you should expect roughly half of comparable tasks to finish within that time and half to take longer. This is a reasonable estimate for planning purposes, but it is not a reliable delivery promise.

Two further findings from the same research help explain how estimates work in practice.

• Estimates tend to cluster around round numbers. Six values account for 54% of all estimates in the SiP dataset. The researchers also identified the tendency to use round numbers as one factor influencing accuracy. Estimates such as “one day” or “one week” can reflect familiar time units as much as careful calculations.
• Small tasks behave differently from larger projects. Across studies, Halkjelsvik and Jørgensen found similar levels of overestimation and underestimation overall. However, for projects requiring at least 100 hours of work, they reported expected overoptimism, with a median time overrun of approximately 20%. In the SiP dataset, tasks estimated at one, two, four or seven hours all have a median actual duration matching the original estimate. Small tasks are therefore not necessarily the main source of estimation problems.

Before requesting an estimate, document exactly what the developer needs to build. Our guide on how to write a product spec developers can build from covers how to define the work clearly. The next step is understanding how to interpret the estimate you receive.

Why do software estimates run late?

Software estimates often run late because task durations have a long right tail. A task can take three times longer than estimated, but it cannot take less than zero time. As a result, a few tasks that run significantly over estimate can push the average well above the typical outcome. Tasks that finish early rarely make up for these overruns. Halkjelsvik and Jørgensen describe this pattern in Time Predictions: “Cases of underrun rarely compensate for cases of overrun. Inefficiency trumps efficiency”.

Four factors explain why this happens: the distribution of task durations, uncertainty that persists when work is poorly defined, the tendency to estimate from an imagined plan rather than historical evidence, and the influence of deadlines mentioned before an estimate is given. The last factor is particularly important for founders because it is one they can control directly.

The long right tail

Consider the 10,266 tasks in the SiP dataset. The median task took exactly as long as estimated, but the average actual duration was 1.36 times the estimate. A quarter of tasks took at least 1.22 times their estimated duration, one in ten took at least twice as long, and one in twenty took at least 3.1 times as long. Overall, 12.9% of tasks took at least twice their estimated time.

The distribution of overruns is even more revealing. The 10% of tasks with the largest overruns accounted for 92% of all overrun hours in the dataset. Most tasks stayed relatively close to their estimates. A small number took much longer, and those tasks had a disproportionate effect on the overall schedule.

This pattern appears across software projects of different sizes.

• Commercial software projects. Todd Little studied commercial projects at Landmark Graphics and found that project duration accuracy followed a lognormal distribution, according to his 2006 paper in IEEE Software. A lognormal distribution describes outcomes where changes can compound multiplicatively. For example, a technical problem might require additional investigation, which delays dependent work and creates further problems.
• Large IT projects. Across 5,392 IT projects, Flyvbjerg, Budzier, Lee, Keil, Lunn and Bester found that cost overruns followed a power-law distribution. This means many projects experienced relatively small overruns, while a smaller number suffered extreme ones. The median project's actual cost matched its estimate, but the mean was 1.8 times the estimate. The 962 projects with schedule data also followed a power-law pattern. The researchers identified interdependent components as a possible mechanism: a problem in one component can trigger delays elsewhere.
• Extreme overruns. In an earlier study of 1,471 IT projects, Flyvbjerg and Budzier reported an average cost overrun of 27%. However, one in six projects experienced an average cost overrun of 200%, alongside a schedule overrun of almost 70%, according to their Harvard Business Review article. These figures come from their particular sample and should not be treated as universal rates.

The long right tail explains a result that can seem contradictory: a project can exceed its total estimated hours even when more tasks finish early than run late.

Halkjelsvik and Jørgensen describe one IT project in which 215 of 443 tasks finished under estimate, while 196 exceeded it. Despite more tasks finishing early, the total predicted effort was 2,723 hours and the actual effort was 3,130 hours, an overrun of approximately 15%.

The SiP dataset shows a similar pattern. More tasks finished under estimate (35.9%) than exceeded it (30.1%), yet total actual hours were approximately 5% higher than total estimated hours.

The reason is that task counts do not tell you how large the overruns are. Ten tasks that finish slightly early might save a few hours, while one task that takes several times longer than expected can add many more hours to the project.

This creates an important problem when planning a project. If individual task estimates represent median outcomes, adding those estimates together does not produce the median completion time for the entire project. The total must account for the distribution of possible outcomes, including the effect of unusually long tasks. Halkjelsvik and Jørgensen recommend adding the predicted mean for each subtask when calculating total expected effort.

Erik Bernhardsson made a similar point in 2019 in his post modelling overruns as a lognormal distribution. His argument was that developers can be reasonably good at estimating the median time needed for a task while still struggling to predict average completion time.

For founders, the lesson is straightforward: a set of reasonable individual estimates can still produce an unreliable project deadline if the combined plan ignores the possibility of unusually long tasks.

The cone of uncertainty

The second factor is uncertainty. Early in a project, requirements may be incomplete, technical decisions remain open, and the team may not know which complications will arise. As these questions are resolved, the range of possible outcomes should narrow.

Steve McConnell describes this through the cone of uncertainty. At the initial concept stage, estimates can be inaccurate by a factor of four in either direction, creating a 16-fold range between the lower and upper estimates. These figures are an illustrative model rather than a measurement of every team's performance. McConnell explains the concept on the Construx site.

However, the cone does not guarantee that estimates will become more accurate simply because a project progresses.

Todd Little's analysis of Landmark Graphics projects found that the uncertainty range remained nearly identical throughout the project, contradicting the common interpretation of the cone. McConnell also acknowledges that estimates may fail to improve when project control is weak or the people estimating the work lack sufficient skill. In these circumstances, uncertainty can persist until the end.

The distinction is important: uncertainty narrows when decisions are made and information improves, not merely when time passes. An estimate requested before the requirements are clear is based on a range of possibilities that the team has not yet properly defined.

Magne Jørgensen makes the recommendation explicit in his 2014 IEEE Software article: avoid early estimates based on highly incomplete information.

For a founder, this means resisting the temptation to demand a firm delivery date before the team understands the scope. An estimate produced after the requirements and technical approach have been clarified is generally a more useful basis for planning.

Estimating the scenario instead of the record

The third factor is psychological. People tend to estimate from the scenario they imagine unfolding rather than from evidence about how similar work has actually gone.

Daniel Kahneman and Dan Lovallo described this problem in a 1993 paper in Management Science. They explained that overly optimistic forecasts arise when people take an “inside view” of a problem, basing predictions on their plans and imagined scenarios.

The inside view asks how the current task should proceed if the plan works. The outside view asks how long comparable tasks have actually taken, including the complications that were not anticipated.

A well-known study by Roger Buehler, Dale Griffin and Michael Ross illustrates the difference. The researchers asked 37 honours students to predict when they would finish their theses. On average, students expected to finish in 33.9 days, but actually took 55.5 days. Fewer than one-third finished by their own best-estimate dates.

Even their worst-case predictions were unreliable. Only 48.7% finished by the date they had predicted on the assumption that everything would go as badly as possible, according to their 1994 paper in the Journal of Personality and Social Psychology.

Asking a developer for a worst-case estimate therefore does not automatically give you a safe deadline. If that estimate is based on the same assumptions as the best-case prediction, it may still exclude problems the developer has not considered.

The study also identified a way to reduce this bias. In one experiment, the researchers eliminated the optimistic bias among participants instructed to connect their predictions with relevant past experiences.

This is the principle behind reference-class forecasting. Instead of relying exclusively on the team's expectations for the current project, compare the work with similar tasks and use their actual completion times to inform the prediction. The approach provides a more realistic basis for estimating what might happen.

The number you said first

The fourth factor is one founders can influence directly: the effect of stating an expected deadline before asking for an estimate.

Research by Jørgensen and Grimstad found that software professionals changed their estimates in response to customer expectations, even when instructed to ignore those expectations. Without a stated expectation, the median estimate was 160 hours. When the customer expected 800 hours, the median estimate rose to 300 hours. When the expectation was 40 hours, it fell to 100 hours. Even an implausibly low expectation of four hours produced a median estimate of 60 hours. These findings are reported in Time Predictions.

Jorge Aranda and Steve Easterbrook found a similar effect in an independent experiment. When a manager casually suggested that a task should take two months, the mean estimate was 6.8 months. Without a suggested duration, it was 8.3 months. When the manager suggested 20 months, the mean estimate rose to 17.4 months. The effect appeared regardless of the estimation technique used.

These results illustrate anchoring. Once a number enters the conversation, it can influence the estimate even when the person providing it tries to remain objective. A founder who announces an expected deadline before asking the developer to estimate the work may unintentionally distort the answer.

Jørgensen's review of estimation research also warns that knowing a client expects a low price or a low number of work hours can contribute to underestimating the effort required. The practical defence is to ask for an independent estimate before sharing your preferred deadline or budget.

One frequently quoted statistic also deserves caution. The Standish Group's 1994 CHAOS report claimed an average project cost overrun of 189%. That figure continues to circulate, but a peer-reviewed review by Jørgensen and Moløkken found that all the surveys they could find from the relevant period and countries suggested average cost overruns of about 30%. They also questioned whether the CHAOS sample was biased towards failed projects.

Rather than relying on the Standish figure, this article uses the findings from surveys reviewed by Moløkken and Jørgensen, which suggest that 60-80% of software projects overrun their estimated effort or schedule, with average overruns of approximately 30-40%.

The central lesson is that overruns are not simply evidence of poor developers or careless planning. They emerge from the distribution of task durations, unresolved uncertainty, optimistic assumptions and the influence of expectations. Better estimates require teams to account for these factors instead of treating a single number as a guaranteed outcome.

What should you ask when someone says two weeks?

Ask questions that turn a single estimate into a range of possible outcomes. Start by clarifying what the number means, because some developers give a best-case estimate while others describe the most likely outcome. Five questions can help you understand the estimate, identify missing work and assess how reliable the proposed timeline is. None requires technical knowledge.

How to use these questions

Ask the first question every time, including when working with developers you trust. It is not an accusation. Research shows that developers can interpret the same estimation instructions differently, even within the same organisation. Clarifying the meaning of the number helps everyone plan around the same assumptions. If the answer is “best case”, you know the estimate is optimistic rather than a typical outcome.

The second question is particularly valuable. A developer who can identify a similar feature and explain how long it actually took is using historical evidence to inform the estimate. This is the outside view: looking at what happened previously rather than relying entirely on how the current task is expected to unfold. If nothing similar has been built before, that is useful information too. The estimate should account for the additional uncertainty.

The third question helps uncover hidden work. Two weeks of coding can become six weeks for the complete feature once testing, code review, deployment, data migration and overlooked requirements are included. Joel Spolsky recommends breaking schedules into tasks that take no more than 16 hours because, as he explains in his essay on evidence-based scheduling, this forces the team to work out what it actually needs to do.

Breaking a feature into smaller tasks does more than reveal forgotten work. It can also increase the total estimate, making it more realistic. When tasks are routinely underestimated, identifying more of the work helps correct that bias.

The fourth question tests how well the developer understands uncertainty. Many people are overconfident about their predictions. In one study reported in Time Predictions, 43% of students missed their own 98% confidence intervals when estimating the time needed for a programming task. A developer who acknowledges a wider range of possible outcomes may have a better understanding of the uncertainty than someone who confidently offers a narrow range. Confidence alone is not evidence of accuracy.

The fifth question is about the influence you have on the estimate. If you announce that a feature must be ready by the first of the month before asking for a timeline, the estimate may shift towards that date. Ask the developer to estimate the work from the specification first. Once you have an independent estimate, share the deadline and discuss whether the scope, resources or delivery plan needs to change.

This approach also helps when assessing a developer's judgement more broadly. Our guide on how to evaluate developers when you can't read the code explores the importance of looking for evidence rather than relying solely on what someone claims.

What should you promise a customer instead?

Promise a delivery date you have a high degree of confidence in, rather than passing the developer's original estimate directly to the customer. In the absence of reliable historical data from your own team, the SiP dataset provides a useful starting point: nine in ten recorded tasks finished within twice their estimate, while three in four finished within approximately 1.22 times their estimate. Keep the original estimate as the team's internal target and use a separate, risk-adjusted date for customer commitments.

Four practices help turn these principles into workable customer commitments.

Keep the buffer separate from the team target

Do not automatically give the developer the padded deadline. The target used to motivate and organise the work is different from the date you promise externally.

Halkjelsvik and Jørgensen explain in Time Predictions that time predictions can influence the performance they are intended to predict. Slightly ambitious targets may improve productivity, but targets that are much too optimistic or too generous can reduce it. Unrealistically short targets can also compromise quality.

Keep the original estimate as the team's working target. The additional time is a contingency buffer for managing uncertainty and protecting the customer commitment. It should not become an invitation to delay the work.

Buffer the feature, not every task

Applying a safety multiplier to every task and then adding those padded estimates together can produce an unnecessarily large schedule. Each task-level multiplier represents uncertainty at that level, and repeatedly applying it does not automatically produce the right confidence level for the entire feature.

The combined risk depends on how the tasks relate to one another. Independent tasks can offset some of their variability, while dependent tasks can compound delays. Flyvbjerg and his co-authors identify interdependencies between project components as one explanation for extreme overruns in large IT projects.

For a feature with several related tasks, estimate the work individually, identify dependencies and uncertainties, and then set a delivery buffer for the feature as a whole. Where possible, base that buffer on the historical performance of comparable features rather than automatically doubling every task.

Do not try to rescue a late deadline by adding people

Adding developers to a delayed project does not guarantee that it will finish sooner. New team members need time to understand the codebase and requirements, and existing developers must spend time coordinating their work. Halkjelsvik and Jørgensen note that doubling the workforce tends to produce less than twice the output per unit of time because coordination requirements increase.

This is the principle behind Brooks's law, commonly summarised as “adding manpower to a late software project makes it later”.

If a deadline is approaching and the work is behind schedule, reassess the scope before adding people. Delivering a smaller, usable feature on the agreed date may be more valuable than delivering the full feature late. Additional capacity is worth considering for future work, but it is not an automatic fix for the current delay.

Be cautious about choosing the fastest estimate

When comparing estimates from several developers or agencies, choosing the shortest timeline can reward optimism rather than accuracy. A provider who consistently underestimates the work may appear more competitive but ultimately deliver late, exceed the budget or compromise quality.

Jørgensen describes this as the winner's curse. In highly competitive bidding rounds focused on low prices, the successful bidder may be the one whose estimate is most optimistic rather than the one whose forecast is most realistic. The same risk applies when buyers select providers primarily on delivery speed.

Compare providers on the assumptions behind their estimates, their track record and what is included in the proposed timeline. If you are comparing quotes for an entire product, our guide to how much it costs to build a SaaS platform provides further context.

The multipliers in the table are based on one company's records across ten years of software development. They describe individual tasks, not complete features built by small startup teams. There is no published equivalent dataset establishing that the same multipliers will reliably predict delivery for every startup.

The most useful buffer is therefore the one supported by your own team's results. Track estimated and actual delivery times for completed features, compare similar work and adjust future commitments based on what the evidence shows. The next section explains how to use that record to make your estimates more accurate over time.

How do you estimate software development time so the next one is better?

Record the estimated and actual time for every task, then use that history to estimate future features. This approach, known as reference-class forecasting, bases predictions on the actual performance of comparable projects rather than assumptions about how the next one should go.

Bent Flyvbjerg defines the method as forecasting “on actual performance in a reference class of comparable projects”, helping to overcome optimism bias and strategic misrepresentation. It directly addresses the problem identified by Kahneman and Lovallo: people tend to predict outcomes from their plans rather than from historical evidence.

Flyvbjerg's approach has three steps: identify a group of comparable past projects, establish the range of their actual outcomes, and use that distribution to forecast the new project's likely result. For a founder with a small development team, the reference class can simply be the team's own completed features.

Five practical steps turn this method into a repeatable process.

Why these steps work

Breaking down work and estimating ranges. Decomposing a feature into smaller tasks helps expose hidden work and can improve estimates, particularly when work is routinely underestimated. However, the method depends on identifying all the necessary components. If some work remains unknown, the estimate must allow for those missing components and unexpected events.

Ranges should also be grounded in historical evidence rather than intuition. In his 2014 summary of estimation research, Jørgensen notes that minimum-maximum intervals tend to be systematically too narrow. He recommends using historical estimation errors to establish more realistic ranges.

Recording actual results and learning from them. Tracking actual time is what makes the process useful over the long term. In research discussed by Halkjelsvik and Jørgensen, students gave less optimistic completion-time predictions when they collected and used the time spent on similar tasks they had already completed.

Not everyone considers tracking actuals against estimates worthwhile. Ron Jeffries, who has criticised the use of story points and estimates in software development, describes this practice as “at best wasteful” in his 2019 essay. His criticism is particularly relevant when estimates are used to judge individual developers rather than to improve planning.

For founders, the distinction is important. The purpose of recording actual time is not to punish developers for overruns. It is to understand how work behaves, improve future estimates and make more realistic commitments.

Using simulations to calculate a delivery date. Once you have enough historical data, you can use it to model possible delivery outcomes. Joel Spolsky described this approach in his 2007 essay on evidence-based scheduling. His method uses developers' historical performance to generate many possible project scenarios, then calculates the probability of shipping by different dates.

For example, a simulation might show that a feature has a 70% chance of being completed within three weeks and a 90% chance of being completed within four weeks. You can then choose a customer deadline that matches the level of risk your business is prepared to accept.

Spolsky promoted this approach through his own project-tracking software, so his endorsement should be understood in that context. However, the underlying principle also appears in the research by Halkjelsvik and Jørgensen: use the distribution of historical estimation errors to calculate expected effort and realistic completion dates.

Why not just use PERT?

PERT, or Program Evaluation and Review Technique, is a traditional method for estimating project duration. Developed for the US Navy's Polaris Fleet Ballistic Missile programme, per the 1959 paper in Operations Research, it uses three estimates for each task: an optimistic duration, a most likely duration and a pessimistic duration.

The traditional formula is PERT estimate = (O + 4M + P) / 6, where O is the optimistic estimate, M is the most likely estimate and P is the pessimistic estimate. The formula gives the most likely estimate four times the weight of either extreme.

The problem is that all three numbers still depend on judgement. People often underestimate how much can go wrong, and their optimistic and pessimistic scenarios may not reflect actual outcomes. Halkjelsvik and Jørgensen conclude that typical use of PERT tends to underestimate the mean values and, consequently, the total time used.

PERT can still be a useful way to think in ranges. However, using your team's recorded estimation errors to inform its ranges makes it more evidence-based than relying on imagined best- and worst-case scenarios alone.

If you are planning an entire first product release rather than an individual feature, our MVP development guide for startups covers how to sequence the work. Combining that planning process with a record of actual delivery times makes your timeline more credible and easier to improve.

Where RocketDevs fits

The biggest challenge for small teams is often the lack of reliable records showing how long previous work actually took. Those records provide the reference point for estimating future tasks and help teams make more realistic delivery commitments. Without them, estimates rely heavily on judgement rather than evidence.

RocketDevs developers work with built-in productivity tracking. The system captures screenshots every 3 minutes on both monitors and records keystroke and mouse-movement activity per minute. This information is displayed on a centralised dashboard, giving clients visibility into recorded on-screen activity and computer usage. When reviewed alongside each task’s original estimate and actual time spent, these records can help teams understand how long work takes and improve future estimates.

Productivity tracking does not, by itself, prove how much meaningful work has been completed or whether a developer is productive. Its value for estimation comes from reviewing the activity records alongside task progress, deliverables and time spent.

We do not claim that RocketDevs developers produce more accurate estimates than other developers, as we do not have the data to support that claim. We can, however, explain how our developers are selected. Each developer completes 6-8 hours of assessment, and only the top 2% of applicants are accepted.

To start building a more reliable record of development time, hire a vetted developer through RocketDevs. Each new hire comes with a 14-day risk-free trial, money back and 100% honoured.

Conclusion: stop treating estimates as promises

A software development estimate is not a deadline. It is a prediction made with incomplete information, and its reliability depends on how well you understand the work, the uncertainty surrounding it and your team's history of delivering similar tasks. Treating a single number as a guarantee is how reasonable plans turn into missed deadlines, strained budgets and difficult conversations with customers.

The practical answer is to make estimation a process that improves with every project. Break features into manageable tasks, compare them with previous work and ask developers to explain their assumptions. Record estimated time alongside actual time, then use the difference to refine future predictions. For customer commitments, choose a delivery date that reflects the level of risk your business can afford rather than simply repeating the developer's most likely estimate.

You do not need perfect predictions to deliver reliably. You need evidence that helps you recognise uncertainty before it becomes a problem. The teams that estimate best are not necessarily the teams that guess the closest on day one. They are the teams that learn from every delivery, plan for what could go wrong and make commitments they can defend with data.

Frequently asked questions

How do developers estimate software development time?

Developers typically break a feature into smaller tasks and estimate how long each will take based on experience. Adding these estimates together can produce a more realistic result than estimating the entire feature at once, particularly when the work is easy to underestimate. However, the quality of an estimate depends on the evidence behind it. Asking how long a similar feature actually took is a useful way to distinguish an evidence-based estimate from one based mainly on assumptions.

Why do software projects take longer than estimated?

The main problem is that overruns tend to be larger than underruns. Most tasks may finish close to their estimates, but a small number can take two or three times longer than expected. No task can finish in less than zero time to offset those delays. As a result, a project can run late even when more tasks finish early than late. In one 443-task IT project discussed in Time Predictions, more tasks finished early than late, yet the project still exceeded its estimate by 15%. Overoptimistic planning and the influence of dates mentioned by customers or managers can make the problem worse.

How much buffer should I add to a software development estimate?

Ideally, calculate your buffer using your team's historical delivery data. If you do not have that information yet, data from one software company provides a starting point. Across 10,266 recorded tasks in the public SiP dataset, a delivery date set at twice the original estimate covered approximately nine tasks in ten, based on our analysis. Keep the original estimate as the team's working target and add the buffer to the date communicated to the customer. Once you have several months of recorded estimates and actual delivery times, replace this general multiplier with one based on your own team's results.

Are story points better than estimating in hours?

There is no clear evidence that relative estimation methods, such as story points, are more accurate than estimates expressed in hours, according to Time Predictions. Halkjelsvik and Jørgensen also found that students using a Fibonacci-style estimation scale produced a median estimate of eight hours, compared with 20 hours when using a linear scale. Changing the unit does not automatically improve accuracy. Whichever method your team chooses, reliable delivery forecasts still depend on tracking actual results and understanding how quickly the team completes comparable work.

How can I make software development estimates more accurate over time?

Record the estimated and actual time for every task, then compare the results to identify recurring patterns. Break features into manageable tasks, use completed work to guide new estimates and ask developers to explain their assumptions and confidence in the proposed timeline. Over time, this creates a historical record that helps you calculate more realistic delivery dates. The goal is not to eliminate uncertainty but to understand it well enough to make commitments your team can meet.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• Derek M. Jones and Stephen Cullum, A conversation around the analysis of the SiP effort estimation dataset, arXiv 1901.01621, 2019
• Derek M. Jones, SiP_dataset, GitHub, the public task file our percentile figures were counted from on 11 October 2026
• Torleif Halkjelsvik and Magne Jørgensen, Time Predictions: Understanding and Avoiding Unrealism in Project Planning and Everyday Life, Springer Open, 2018
• Bent Flyvbjerg, Alexander Budzier, Jong Seok Lee, Mark Keil, Daniel Lunn and Dirk W. Bester, The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution, Journal of Management Information Systems, 2022
• Bent Flyvbjerg and Alexander Budzier, Why Your IT Project May Be Riskier than You Think, Harvard Business Review, September 2011 (authors' copy)
• Bent Flyvbjerg, From Nobel Prize to Project Management: Getting Risks Right, Project Management Journal, 2006
• Todd Little, Schedule estimation and uncertainty surrounding the cone of uncertainty, IEEE Software, 2006
• Steve McConnell, The Cone of Uncertainty, Construx
• Daniel Kahneman and Dan Lovallo, Timid Choices and Bold Forecasts: A Cognitive Perspective on Risk Taking, Management Science, 1993
• Roger Buehler, Dale Griffin and Michael Ross, Exploring the "planning fallacy": Why people underestimate their task completion times, Journal of Personality and Social Psychology, 1994
• Jorge Aranda and Steve Easterbrook, Anchoring and adjustment in software estimation, ESEC/FSE, 2005
• Magne Jørgensen, What We Do and Don't Know about Software Development Effort Estimation, IEEE Software, 2014
• Magne Jørgensen and Kjetil Moløkken, How large are software cost overruns? A review of the 1994 CHAOS report, Information and Software Technology, 2006
• Kjetil Moløkken and Magne Jørgensen, A review of software surveys on software effort estimation, ISESE, 2003
• D. G. Malcolm, J. H. Roseboom, C. E. Clark and W. Fazar, Application of a Technique for Research and Development Program Evaluation, Operations Research, 1959
• Joel Spolsky, Evidence Based Scheduling, Joel on Software, 2007
• Ron Jeffries, Story Points Revisited, 2019
• Erik Bernhardsson, Why software projects take longer than you think: a statistical model, 2019
• Hacker News discussion of Bernhardsson's post, via the Algolia HN API
• Brooks's law, Wikipedia