Software project estimation methods are where most software projects are won or lost, long before a line of code is written. A bad estimate does not just make a project late. It poisons the relationship between the team building the software and the business paying for it, because every week past the promised date feels like a broken promise, even when the work itself is going well. This guide compares the estimation methods we actually use at MTD Technologies, explains when each one works, and shows how to pad honestly, re-estimate without drama, and keep an estimate believable when reality intervenes.
This article is written for business owners, product managers, and non-technical founders who have to approve a quote, and for developers who have to defend one. By the end, you will be able to read any software quote and tell whether the number behind it is a guess, a method, or a sales tactic. You will also know which questions to ask before you sign, and which answers should worry you.
Why most software estimates fail before coding starts
Estimates usually fail for reasons that have nothing to do with coding speed. The scope is described in a sentence when it needs a paragraph. The person estimating has never built the specific integration before. The business assumes that because a feature looks simple on screen, it is simple underneath. And almost always, the estimate covers the happy path only: the user does everything right, the third-party API behaves, the data is clean, and nobody changes their mind.
In our experience across more than 300 projects over nine years, the single biggest cause of overruns is not slow developers. It is undiscovered work. A login page is not just a login page once you add password reset, email verification, account lockout, social sign-in, and the admin view of users. A payment integration is not just a checkout button once you add refunds, failed payments, tax rules, and reconciliation reports. Good estimation is mostly the discipline of finding that hidden work before you price it, not the arithmetic you do afterwards.
Software project estimation methods compared
Three methods dominate real agency work: three-point estimation, story points, and function points. Each answers a different question, and much of the confusion in software quotes comes from using one method where another belongs. Here is how they compare in practice, not in theory.
- Three-point estimation answers: how long could this take, realistically, in the best and worst cases? Best for fixed-price quotes and client-facing timelines.
- Story points answer: how big is this piece of work relative to work we have done before? Best for agile teams with a stable velocity over several sprints.
- Function points answer: how much functionality are we actually buying, measured independently of who builds it? Best for large, formal procurements and benchmarking across vendors.
Three-point estimation: the method behind honest fixed quotes
Three-point estimation asks for three numbers per task: the optimistic time, the most likely time, and the pessimistic time. The classic formula weights the most likely case most heavily: expected time equals optimistic plus four times most likely plus pessimistic, all divided by six. The formula matters less than the conversation it forces. When a developer has to name a pessimistic case, they have to say out loud what could go wrong, and that is where the hidden work surfaces.
Take a typical task: building a booking form with payment. The optimistic case might be three days, assuming the payment provider documentation is accurate and the client supplies content on time. The most likely case might be five days. The pessimistic case might be twelve days, once you count payment webhooks failing in testing, refund flows, timezone handling for bookings, and two rounds of design changes. The weighted estimate lands around six days, but the real value is the twelve-day figure: it tells the client what the risk looks like and lets you agree in advance what happens if it materialises.
Story points: relative sizing for teams that ship every sprint
Story points deliberately avoid hours. A team sizes each piece of work relative to a reference task everyone knows: this feature is about twice as complex as that one, so it gets twice the points. After a few sprints, the team learns its velocity, the number of points it completes per sprint, and can forecast how many sprints a backlog will take. The strength of the method is that it sidesteps false precision. Nobody argues about whether a task is 11 or 13 hours; they argue about whether it is bigger than the last similar task, which is a conversation humans are actually good at.
Story points fail in exactly the situations where buyers most want them to work. They cannot be compared across teams, because one team’s five points are another team’s thirteen. They cannot be converted into a fixed price without knowing velocity, and velocity does not exist for a new team or a new project. Any agency that quotes you a fixed price derived from story points on a project it has not started is converting an unknown into a promise. Ask instead what the team’s velocity is on comparable past work, and how many sprints of buffer sit behind the quoted date.
Function points: measuring what you buy, not who builds it
Function points count the functionality delivered to the user: inputs, outputs, enquiries, files, and external interfaces, each weighted by complexity. The result is a size in function points, which can be converted into effort using industry or historical data. The appeal is vendor independence. If two agencies bid on the same specification, function points let you compare the size of what each proposes to build, rather than comparing their hourly rates and hoping the scopes match.
The cost is effort. Counting function points properly requires a trained analyst and a detailed specification, which is exactly what early-stage projects do not have. For a small or medium business project, the counting exercise can cost more than the insight is worth. Function points earn their keep on large procurements, government tenders, and multi-vendor programmes, where comparability matters more than speed. For a typical custom web application or mobile app build, three-point estimation plus a clear scope document gets you further, faster.
Padding honestly: the difference between contingency and dishonesty
Every experienced developer pads estimates, and every honest one will tell you so. The question is never whether padding exists, but whether it is visible and justified. Hidden padding, where a five-day task is quoted as ten days with no explanation, destroys trust when the client discovers it, and it always gets discovered, usually when the work finishes early and the invoice does not shrink. Visible contingency, where the quote shows a base estimate plus an explicit risk allowance for named risks, builds trust, because the client can see what they are paying to insure against.
As a rule of thumb from our own delivery history, we treat contingency as a function of uncertainty, not a flat percentage. Well-understood work with a stable specification carries a small allowance, typically 10 to 15 percent. Work involving a new integration, a third party outside our control, or a specification still being written carries 25 to 40 percent, and we say so in the quote. Work that is genuinely exploratory should not be fixed-priced at all; it should be time-boxed, with a review point where the estimate is rebuilt from what was learned.
Re-estimation triggers: when the number must change
An estimate is a snapshot of understanding at a point in time. As understanding improves, the estimate should change, and the contract should say so. The triggers we use with clients are simple and agreed up front, so re-estimation never feels like a surprise invoice.
- Scope change: a new feature, a removed integration, or a changed user flow. Re-estimate the affected work only, and show the delta, not a new total from nowhere.
- Discovery: the data migration reveals dirty data, the API lacks a promised endpoint, or the legacy system has no documentation. Re-estimate once the discovery is quantified, not on the day it is found.
- Dependency delay: content, approvals, or third-party access arrives late. The schedule moves by at least the delay, and usually more, because context-switching costs a team days, not hours.
- Velocity evidence: after two or three sprints, actual throughput is consistently above or below the forecast. Re-forecast the remaining backlog from measured velocity, in both directions. Good news counts too.
From our experience: what actually keeps estimates believable
Three habits separate estimates that survive contact with reality from ones that collapse at the first surprise. First, estimate in small pieces. A single 200-hour line item hides every assumption inside it. Twenty 10-hour items, each with its own optimistic and pessimistic case, expose them. Clients rarely object to detail; they object to being asked to trust a black box.
Third, track actuals against estimates and publish the comparison internally after every project. Teams that never look back repeat the same optimism forever. Teams that do learn, for example, that integrations always take twice as long as the first estimate, or that admin panels are consistently underestimated because nobody counts permissions properly. That institutional memory is the real asset behind any estimation method, and it is why an agency with nine years of delivery history can estimate better than a brilliant individual working alone. The method is the easy part. The memory is the work.
Frequently asked questions
Which software project estimation method is most accurate?
None is universally most accurate. Three-point estimation is most accurate for fixed-price quotes on familiar work, story points for forecasting within a stable agile team, and function points for comparing bids on large, well-specified procurements. Accuracy comes from matching the method to the situation and from the team’s track record on similar work, not from the formula itself.
Why do software quotes vary so much between agencies?
Because quotes differ in scope, not just price. One agency may include testing, deployment, and review cycles, while another quotes build time only. Others may assume different integrations, hosting, or support. Always compare the itemised scope line by line before comparing totals, and ask each vendor what their price excludes.
How much contingency should a software estimate include?
It depends on uncertainty. Well-understood work with a stable specification typically needs 10 to 15 percent. Work involving new integrations or third parties outside the vendor’s control needs 25 to 40 percent. Genuinely exploratory work should be time-boxed rather than fixed-priced, with a review point where the estimate is rebuilt from evidence.
When should an estimate be re-done instead of defended?
Re-estimate when scope changes, when discovery reveals materially different work, when a dependency delay shifts the schedule, or when measured velocity over two or three sprints contradicts the forecast. Defending an estimate that new evidence has disproven helps nobody; a revised estimate with stated reasons preserves trust.
Can story points be used to price a fixed-price project?
Only with great caution. Story points are relative within one team and meaningless without that team’s measured velocity. A fixed price derived from story points on a new project converts an unknown into a promise. Ask for the team’s velocity on comparable past work and the buffer behind the quoted date before accepting such a price.
If you are planning a build and want an estimate you can actually plan around, talk to a team that will show its working. Our custom software development process starts with an itemised, assumption-stated estimate, so you know exactly what the price covers and what would change it. Contact us with your project outline and we will walk through the estimate with you, including the parts other quotes leave out.