Rules of Thumb for Software Development Estimations
I once lost half a Sunday to a single question: “How long would it take us to build a mobile bank?” The coffee in my hand was still hot, yet my brain was already spinning through compliance, payments, KYC flows, the whole nine yards. Estimation sneaks up on you like that — one innocent question, and suddenly you’re pricing an entire year of your life.
Software estimates have punched me in the face from both directions: as the engineer begging for clearer specs and as the manager standing in front of a sales pitch that needed numbers yesterday. I’m sharing what’s worked for me (and the bits that spectacularly failed). No silver bullets, just a handful of rules of thumb you can steal or ignore.
If you’re early in your career, pay extra attention — getting this wrong repeatedly will age you faster than energy drinks and late-night deploys combined. (I found that out the wrinkly way.)
Back to that banking question. My gut said “roughly a year with a small crew, maybe seven people.” I also warned that the number was soft — confidence maybe 40 % (I actually said that out loud, which helped later). What I didn’t do, and later regretted, was charge for a proper discovery sprint. Some teams treat estimation itself as a paid mini-project — it filters out tyre-kickers and gives you breathing room to be precise. Something to keep in mind next time a sales deck needs a price tag yesterday.
We built the thing. Ten months of coding, permanent scope haircuts, one shortcut using a partner’s banking license, and a backlog longer than a Swiss winter. You could say the estimate was “right,” but only because we trimmed features like crazy — one payment provider, one onboarding flow, nothing fancy. Scope reduction is the only diet plan that actually works in software.
💡 Estimates don’t magically align with reality; reality gets squeezed until it fits the estimate.
I’ve missed in both directions plenty of times. Overshot a custom CMS component significantly (client thought we were padding invoices). Undershot a fixed-price job that needed a library upgrade — the dependency graph exploded and we struggled to meet the deadline. Good times.
Enough war stories. Let’s talk mechanics.
Why Do Estimations at All?
Someone, somewhere, signs a cheque. That someone wants a number. Without at least a guess, projects never start, budgets never get approved, and accountants sleep too well. But an estimate isn’t just a date — it’s the date plus a confidence level. “Four weeks at 60 %” lands very differently from “Four weeks, trust me.” Skipping the confidence bit is how heated arguments get scheduled six months later.
Here’s what estimates buy us:
- Resource Allocation: They keep head-count roughly aligned with scope. (Stakeholders often prefer numbers that look optimistic on a slide deck — the polite word is “aspirational.” Push back gently but firmly.)
- Collaboration: A shared timeline forces the product folks, designers, and engineers into the same calendar. Without it, integrations drift and nothing ships.
- Sanity Check: Even a coarse Gantt lets you spot the month where three critical paths collide. I’m not entirely sure this scales to 500-person orgs, but for mid-size teams it prevents weekend panic.
So yes, estimates are a necessary evil. Might as well get better at them.
Estimations in Software Projects
Time-based estimates are notorious for triggering the planning fallacy (Kahneman & Tversky wrote about this almost 50 years ago). Many teams switch to relative units — story points, T-shirt sizes, whatever — and only convert to calendar time when absolutely forced to. From what I’ve seen, velocity in abstract units breaks fewer hearts than “hours.”
Still, uncertainty is the roommate you can’t evict. I prefer starting wide (“6–12 months, 30 % confidence”) and tightening over time rather than the other way around. Telling a sponsor the timeline shrunk after a spike week feels like winning free coffee; telling them it doubled feels like cancelling Christmas.
🚨 Bad news grows with age. Surface uncertainty early while it’s cheap.
Rules of thumb I lean on:
No two projects are the same: Even if both are “just another chat app,” the second one will have an SSO provider nobody has used before or a data- residency clause that nukes your caching layer. Past work informs, never dictates.
Buffer for humanity: I tack on roughly 25 % for flu season, vendor silence, and people having babies. Could be overkill; rather that than explaining why progress halted because DHL lost the 2FA tokens. (Been there.)
Communication is king: Over-communicate, then double it. A quick “still waiting on legal” Slack at 9 a.m. beats a surprise delay on Friday evening.
I’ve learned most of this by missing deadlines — not proud, just honest.
Wrong Ways to Do Estimations
A few techniques I avoid like deploying on a Friday:
The blind guess: Throwing a number to stop the conversation only pauses the pain — it returns multiplied. Our internal joke is that every project is “six months” by default; the punchline is the inevitable follow-up questions.
One size fits all: “Build me a shop” can mean WooCommerce with Stripe or SAP integration with warehouse robotics. Always unpack the nouns.
💡 Ask until both sides can sketch the same system on a whiteboard without speaking.
Forgetting the meeting tax: Raw coding hours × 1.5 is my quick multiplier. Yours might differ; track it for a sprint and you’ll never go back.
The fixed mindset: Treating the first number as sacred. My loop: build → learn → adjust → repeat. If estimates only ever move in one direction, you’re not learning — you’re guessing.
Alright, enough negativity. Here’s what has worked.
Proper Ways to Estimate
Below is a grab-bag of tactics. They’re subjective, they’re messy, but they keep me mostly out of trouble.
An estimate that only includes time implies certainty. The moment you add an uncertainty multiplier, stakeholders see the risk instead of assuming it away.
A favorite write-up on ranged estimates
Break work recursively: If a chunk is bigger than two weeks, split it and ask again. Repeat until every leaf fits inside a sprint. Simple, boring, shockingly effective.
Use historical data: Jot down how long things actually took. Future you will thank present you. I ignored this advice for years and paid for it in stress.
Group estimation techniques: Planning Poker, Wideband Delphi, even plain “silent write-down then reveal.” Multiple brains smooth individual bias. I could be wrong but I’d say teams trimmed variance by about a third once we started doing this.
Roger S. Pressman.
Ranged estimates: “10–15 days” beats “12 days” every time. Remember to emphasise the upper bound — some listeners only hear the smaller number.
Seek mentorship: Read post-mortems, watch engineering talks, lurk in other teams’ retros. Someone else already paid the tuition — steal their lessons.
Hold the line against authority pressure: If the VP wants three weeks but your gut (and data) say five, explain the trade-offs. Caving produces short-term smiles and long-term weekends in the office.
Nobody nails this on day one. Keep iterating.
Refining Estimates
Numbers decay. Treat them like yoghurt, not granite.
Track vs. baseline: I use a simple spreadsheet: original estimate, current forecast, delta. Seeing the drift in black and white keeps wishful thinking in check.
Milestone checkpoints: Every time we ship something demo-worthy, we pause for half an hour and re-price the remainder. I screwed this up for 18 months before making it a ritual.
Broadcast changes fast: Surprises age badly. If you’re stuck, say so before the status meeting — not during. (I should be upfront — I still catch myself hesitating to raise the flag.)
The objective is simple: no nasty surprises.
Helping Your Manager Plan Better
Your manager is juggling more inputs than a router during DDoS. Make their life easier:
- Proactive updates: Send a one-liner when something shifts. They’ll relax; you’ll avoid micromanagement.
- Translate tech to business: “Blocked on C++ ABI mismatch” means nothing; “We risk missing the marketing launch” lands.
- Co-own risk lists: Brainstorm worst-cases together, stick probabilities next to them, revisit weekly.
- Stay flexible: Last-minute reprioritisation is painful, but rigidity kills projects faster.
They’ll notice. Trust me.
Work Culture Affects Estimations Accuracy
Accuracy thrives where questions are welcomed and failure is treated as data. If you’re in a position to tweak culture, start small:
- Normalize “stupid” questions: Requirements repeated three times cost minutes; ambiguous tickets cost weeks.
- Post-mortem everything: Celebrate fixes, not blame. Document lessons, or you’ll pay tuition twice.
- Embrace change: New tools appear yearly — some actually reduce estimate variance. Pilot, measure, adopt or drop.
- Cross-pollinate estimates: Interns guess, seniors calibrate, everyone learns. Collective IQ > solo genius.
Advice going forward
Estimation isn’t about perfect accuracy — it’s a conversation starter attached to a price tag. Maintain the dialogue and the numbers matter less than the trust you build.
TL;DR;
- Always be estimating (and re-estimating).
- You’ll be wrong until you’re less wrong; then you’ll still miss occasionally.
- Group estimates beat solo ones.
- Capture uncertainty explicitly.
- Over-communicate progress and risk.
- Experiment with techniques; keep what works.
- Choose workplaces that encourage questions and post-mortems.
Keep at it, and the numbers will start behaving.
Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.
Other Newsletter Issues:
Worried your codebase might be full of AI slop?
I've been reviewing code for 15 years. Let me take a look at yours and tell you honestly what's built to last and what isn't.
Learn about the AI Audit →No-Bullshit CTO Guide
268 pages of practical advice for CTOs and tech leads. Everything I know about building teams, scaling technology, and being a good technical founder — compiled into a printable PDF.
Get the guide →
54 Comments
Like your visuals and overall breakdown.the highlighted words, maybe put more visuals on their importance instead of highlighting :notes make it clear need to know more and I most certainly do.
Thanks for your feedback! I’ll do better in the future
I was once in a meeting with a customer who was unhappy part of the project was behind (a highly complex subsystem with vague requirements being understood on the fly), a senior architect consultant they brought in to analyze why we were late and our leadership team. After going over the project status and designs in great detail he looked at them and was like “what’s your beef? They are doing all the right things and building great stuff.” They said “but they are over schedule”. The guy rolled his eyes and said “look, you basically asked them how long it would take to come up with a clever idea to solve a problem no one has done before! They said x weeks and it took y weeks cause their guess was off and they found z problems that were unknown at the time. That happens with GUESSES!”
They left us alone and let us get on with it after that.
great story Joe! Thanks for sharing 🙂
Excellent article. Estimation and specially size estimates are always missing in software projects.
Thank you for showing the justification and ideation of micromanagers. Click and fire.
Wonderful article and thoughts. These strategies will help me to better scope out tasks with my team. Thank you!
Yes, this is an excellent article👍 However how would the details in the article apply to only a Programing Team of ME, MYSELF, & I.❓ I’ll do some more cogitating w the article to see what factors could be used for my PROGRAMMIMG TEAM, of ME, MYSELF, & I. Thank You for writing this Technical Article. It’s in my ‘POCKET’
My rule of thumb is to always 1.5x or 2x my estimates depending on the size of project. For smaller projects I like to double. And for bigger projects I’ll usually do 1.5x to account for unknown unknowns. Also don’t forget to take into account your teams vacations during the length of the project.
“Plans are worthless, but planning is everything.” –Eisenhower
I’m a CRO and for that last 20 years I’ve taken any estimate given to me by Dev for new products and/or new features to existing products and 3Xed that estimate. It’s usually very close to actual release date and keeps customers and salespeople happy. There are simply too many unknowns for Dev to contend with and they are also essentially “forced” to provide unrealistic delivery dates to accommodate a business plan or a capital raise. If one major unknown pops up, or one key developer leaves, or there is a “fire” on different product that requires attention, the project will experience major delays. – My 2 cents.
Though, how do you manage the business side of the house after telling them it will actually take 3x longer? If biz doesn’t accept the longer timeline, the environment will become miserable.
Integrate your business partners into your project. They should attend your weekly meetings such as project progress, bug fix priorities, requirement trade off discussions…
Read “The Mythical Man-Month,” by Frederick Brooks
Thanks, this is very insightful
Another thing, worth to be mentioned, is that the initial estimates are more like a focus point, that is used to synchronize the project processes. If you can’t meet the hard deadline, it’s usually acceptable to sacrifice some optional features, but not to compromise the quality of the main use-cases, while for the other cases the deadline is flexible, but the feature-rich product is must have.
You should know that “Rules of Thumb” is not a good idiom to use due to its origin. Men were allowed to beat their wives as long as the stick was no thicker than the size of their thumb.
I highly doubt that’s true for the whole world, maybe in the US?
Oh, yes. That is true indeed.
Just because it was mentioned in a movie doesn’t make it true. There is no evidence to support this claim; in fact, English common law did not allow wife-beating at all.
You should know that that is wrong.
this statement is erroneous https://en.wiktionary.org/wiki/rule_of_thumb the etymology is from 1658 using the thumb as an imprecise measurement for a “ynche” (today know as “inch”). https://www.theguardian.com/notesandqueries/query/0,,-7903,00.html
Comments like this are why software engineering is a male dominant field.
In my country we call it a “rule of fist”. Take that how you you will.
Excellent approach! Thanks a lot for sharing!
Reminds me of the 80/20 rule, or so it seems to apply in my life with software development: the last 20% of a project takes 80% of my time. Am I saying that right? -_- Anyhow, I find that if I time my original estimate by 3x, all is well.
I enjoyed your article. Thanks.
Cheers!
I always multiply software estimates by pi, and I’m usually pretty close!
The actual needed time is two times the estimate. Using pi as a multiplier gives from for extras, lazy days, setbacks and keep you still within the plan.
Never give an estimate before you are delivered full agreed upon requirements by business and IT.
Nice Sim City 2K reference in there
Software estimation is just wrong. It doesn’t matter how good you try to estimate. You’ll never be right.
Do not estimate, do projection instead.
I understand the industry expect a number and a budget. But this is just brought in software development from other fields. It simply doesn’t apply in software development and we need to change the way we approach it.
If us, developers, do not understand this we have no chance project managers and business will ever get it.
Estimation, the ones with some value, are possible only when every detail of what you have to do has already been analyzed. And by the point you do that kind of analysis you might as well implement the feature instead.
#noestimate
#noestimates *
👍#noestimates
Imagine a world where we are not talking about applications, programming… But instead we are dealing with engineering. Only estimation needed is the time to create the technical documentation. Enginnering happens on paper. Make clients pay for the technical documentation. Having good documentation makes development quite predictable. All this agile, Jira, task, story BS is making us engineers look like idiots. Imagine building a skyscraper and using BS technics/tools we are using in software development…
#noestimates
This is perhaps one if the very few articles I enjoyed reading.
1. Figure out how much ideal engineering time it would take to do the task if everything is described accurately and there are no interruptions.
2. Multiply by 2 and shift to the next higher unit of measure, e.g., hours to days, days to weeks, weeks to months.
So if the result of step 1 is “4 hours”, then the final answer is “8 days”.
So basically, if the estimation is 1 year, I should call it 2 decades, right? 😂
This is an awesome write up. Several very good points to reference when speaking with the business on estimates.
What if, you figure out what is the most important feature to build at the current time, and then ensemble/mob program the h*ll out of it, no estimates or planning needed, any reasonable deadlines will be met as you can not build it any faster.
Rinse and repeat, absolutely no need for estimates, and break it down into small enough chunks, you can project/predict when a certain feature, just as well as when you spend hours on estimating
Changing from Scrum to this with my team, doubled our output
* when a certain feature is finished
What do you mean by “you can predict when a certain feature is finished, just as well as when you spend hours on estimating”? How are you going to predict when a certain feature is finished, if you don’t estimate it? Or are you saying that you can’t properly estimate anyways and hence always have a bad prediction?
Management is always challenging on the estimation. Customer vs vendor.
What about quality? I can do the same job by spending 4 hours, writing a code that smells, without tests and possibility to extend the logic.Or I can spend 2 days, and simplify adding a new logic. Usually we dont take into account such cases.
Yes we don’t count on that. In estimation either one is problematic. Too high or too low. We can’t help but privide it as a range.
Thank you for writing this article. I 100% agree with it.
It’s hard to believe but I dealt with a senior designer once who did not want to give estimates. I remember being surprised. It seems so obvious why estimate are needed that I did not know what to say. This article explains why estimate are needed, how to go about it, and how to improve and work as a team very well. I will definitely share this article with my pears, and ask software designers who don’t want to provide estimates, or are struggling with it, to read it.
From my experience, it’s because if they do so they would usually be asked to come up with a more ‘desirable’ estimate. After a few rounds of this, they would see the whole exercise as futile.
I wanted to share ethat this looks like an interesting and quality article. Also, I’m personally strongly averse to the public persona of Scott Adams – so seeing his work deterred me from reading the article. I’m not asking you to make any changes, but I want to share my personal response. Best of luck.
Apparently Adams isn’t flavour of the month but when one conflates the art with artist one deprives oneself of the treasures such as the Wagnerian operas.
In any case an excellent article which brought a few wry smiles.
Tossed decades of guidance out the window and ignored that the business projection and technical delivery estimate are two entirely different data points.
Projecting the cost and time of software delivery is far easier than all this.
Very verbose article with no concrete recipe, rule of thumb is as follows:
1) Generic estimate at first
2) Estimate refined by SA, Tech leads
3) Estimate further refined by Developers
Anyone who claims they can predict a new project on some “magic” principles, has no idea about IT development
Very interesting article. Thank you for sharing it .100% agreed from my 16 years of experience
Estimating dev time is tricky – aim too short, and you’re rushing; too long, and you’re wasting time. Always add extra time for unexpected bugs and team issues because stuff always comes up. Keeping estimates flexible and updating everyone often helps avoid most headaches. Just think of it as adding a buffer for reality.
Estimating software projects always feels like a tightrope walk between under-promising and over-delivering. The approach of giving a range to capture uncertainty is sound advice; it’s something I’ve started doing more often. Honestly speaking, I’ve found that adding a healthy buffer to any estimate not only accounts for the unexpected but also gives the team breathing room to ensure quality. Communication, though often highlighted, really can’t be stressed enough. Keeping everyone on the same page can mean the difference between a project that spirals out of control and one that moves forward smoothly. In my experience, a mix of gut feeling polished with historical data tends to hit closer to the mark than any other method I’ve tried.
Estimating in coding? It’s like guessing how long a surprise road trip will take. Adding some extra time helps when stuff goes sideways – lets you keep the quality up without burning out. Key is talking it out clearly so everyone stays on the same page. Blending what you’ve done before with what you feel can work out okay. Remember, it’s about the team vibe, not just crunching numbers.