BlogGuides
GuidesDevplan
Software project estimation with AI: start from the code
Why software project estimates made in a meeting miss, a simple method that works (ranges, past projects), and how AI estimation sizes work from your code.
Short answer: Software project estimation is forecasting how much work a feature or project will take, usually in days or weeks of engineering time. Estimates made in a meeting, before anyone opens the code, tend to miss. Give a range instead of one number, check it against similar past work, and size it from the code the work will change. Devplan does the last part: it maps the work to the services and files it touches and gives a size and a range of days that your leads review.
A note before we start. We build Devplan, which estimates projects from your code. The method below works with a spreadsheet and your own Git history too.
What is software project estimation?
Software project estimation is the work of predicting the effort and time a piece of software will take, before it is built. Teams use the estimate to decide what fits in a quarter, what to tell a customer and which project goes first.
There are a handful of common techniques, and most teams mix two or three:
| Technique | How it works | Works best when |
|---|---|---|
| Expert judgment | An experienced engineer gives a number from what they know | The person has built something very similar |
| Planning poker | Each person picks a card privately, everyone reveals at once, and the team talks through the differences | The team needs to agree on scope as much as on size |
| Analogy | Compare the new work with a similar finished project | You keep records of past projects |
| Bottom-up | Split the work into small tasks, estimate each, add them up | The design is clear enough to list the tasks |
| Three-point | Give an optimistic, a likely and a pessimistic number, then combine them | The work has known risks |
| Parametric models | A formula such as COCOMO turns size measures into effort | Large projects with years of historical data |
AI estimation is a newer addition. AI estimation from the code means sizing a piece of work by the parts of the codebase it will change, the services, files and dependencies, instead of by a number agreed in a meeting. Devplan gives that size as a range of days, and an engineering lead reviews it before it goes on the roadmap.
Why software estimates miss
Software estimates have missed for a long time, and by a fairly steady amount. A review of surveys on software effort estimation by Kjetil Moløkken-Østvold and Magne Jørgensen at Simula Research Laboratory found that most projects, 60 to 80%, overrun their effort or schedule estimates, and that the average effort overrun is 30 to 40% (the review is part of Moløkken-Østvold's 2004 PhD thesis at the University of Oslo). The same review found that expert judgment is by far the most common way teams estimate.
Planning poker is a good example of how that judgment gets made. Mountain Goat Software, which popularized it, says the value "is also the conversation that happens when people see the work differently" (Mountain Goat Software). That conversation is useful. The trouble is what the conversation can't see.
Here is a typical example. Six people look at a ticket called "Usage alerts for account owners". Nobody has opened the code for it yet. The cards come back as 3, 5, 5 and 8, the team settles on 5, and the plan gets built on that number. Three weeks in, the work turns out to touch the accounts service as well as the web app, and the alert emails need a template the team hasn't built. Nobody guessed badly. The information was in the code, and nobody had read it yet.
A method that holds up: ranges and past projects
You don't need special tools to estimate better. These four steps work in a spreadsheet:
- Write down the scope, and what's out of it. An estimate is only as good as the description it estimates. A short spec with an "Out of scope" line removes half the arguments later. Our guide on how to write a PRD covers what goes in one.
- Find two or three similar past projects. This is reference class forecasting: instead of building the estimate up from the details of this project, start from how long similar projects actually took. Bent Flyvbjerg describes it in From Nobel Prize to Project Management (Project Management Journal, 2006) as a way to correct for optimism.
- Give a range, not a number. "6 to 8 days" says what you know and what you don't. A single number hides the uncertainty, and people remember it as a promise.
- Look at the code before you commit, and narrow the range as you learn. Which services does the change touch? Which files? Is there a migration, a new dependency or a public API change? Each answer moves the range.
Step 4 is the one teams skip, because it takes an engineer an hour or two per project. It's also the step where AI helps most.
What AI estimation from the code looks like
An AI model that can read your repository can do the first pass of step 4 in minutes. Given a spec, it can find the services and files the change is likely to touch, spot shared code that other teams depend on, and compare the change with similar ones in your history. That turns "it feels like a 5" into "this touches 2 services and about a dozen files".
AI can't know everything that sets a date. It doesn't know that your best engineer on the accounts service is on leave next week, that the team has a release freeze, or that the scope will change after the next customer call. So treat an AI estimate as a first estimate. An engineering lead reads it, adjusts it and owns the date.
The difference from the meeting is where the conversation starts. Instead of debating a number nobody can check, the team reviews a list of services and files, and argues about the parts that are still uncertain.
How Devplan Projects estimates a project
In Devplan, a project starts from a customer request or a spec. Devplan maps the work to the code it will change, down to the services and files, and gives the project a size with a range of days, for example "Medium: 2 services touched, 6 to 8 days". Your leads review the estimate and adjust it before a date goes on the roadmap.
When the plan is agreed, the stories go to Linear or Jira as tickets, so the team keeps working where it already works. If you use Linear, our guide to Linear AI shows how those tickets arrive with their context, and Linear vs Jira compares the two trackers.
Frequently asked questions
What is software project estimation?
Software project estimation is predicting the effort and time a piece of software will take before it is built, usually as a range of days or weeks. Teams use it to plan quarters, set expectations with customers and decide what to build first.
What are the main estimation techniques in software engineering?
The common techniques are expert judgment, planning poker, estimation by analogy, bottom-up estimation, three-point estimation and parametric models such as COCOMO. Most teams combine two or three, for example planning poker for small items and analogy for larger projects.
How do you estimate software development time?
Write down the scope, compare it with two or three similar past projects, give a range rather than a single number, and check the code the work will change before you commit. Narrow the range as you learn more.
Can AI estimate software projects?
Devplan gives a first estimate from your code: it maps a project to the services and files it will change and gives a size and a range of days. AI is good at that first pass, but it can't know your team's capacity or future scope changes, so a lead should review and adjust every AI estimate.
What is a software project estimation example?
An example: a feature that adds usage alerts for account owners touches 2 services, the accounts service and the web app, and about a dozen files. Similar past changes took a week, so the estimate is a range of 6 to 8 days, which a lead reviews before it goes on the roadmap.
Plan with a number your code agrees with
Get a first estimate from your own code. See how Devplan sizes a project.
About the author. Chris Bee is the co-founder and CEO of Devplan.