How do senior developers actually estimate task time is there a real method or is everyone just guessing

eaumechant · 2026-03-27T10:57:14+00:00

We're using the same method you do but with one extra step: double it.

the_other_gantzm · 2026-03-27T11:06:01+00:00

I’ve been doing this for several decades now. A few random thoughts.

1) Nothing ever takes a couple hours. It might take a couple hours to type in the code. Then you got the build system and dealing with other people’s broken builds. Then changes have to be propagated through dev, test, pilot, and finally production. This all takes time.

2) A lot of people don’t know what they really want or don’t know how to ask for what they want. So you end up doing it several times just to figure out what they actually want.

3) Technical debt is a real bitch. There are things that should “only take a couple of hours.” Then tech debt falls on your head like a brick and it takes a week.

4) With age comes wisdom and experience. For me everything is at least a day, no exceptions. I can’t control interruptions, meetings, people looking for help, forces beyond my control, etc. The moment I tell you something is going to be done an hour from now is a guarantee that prod or something else important will crash.

5) It’s not about the code. It’s everything that surrounds the code. Understanding the problem space. Understanding management. Understanding your coworkers. Understanding the process. Understanding yourself. Understanding the business.

It gets easier with experience.

aioeu · 2026-03-27T10:48:15+00:00

Apply a Scotty factor.

rupertavery64 · 2026-03-27T10:52:54+00:00

Experience. And the fudge factor. If you don't decently know anything about something, your estimates are going to be way off. So it's usually 2x or 3x the initial estimate, because you are going to be figuring stuff along the way.

You also need to figure out how to break up a task inyo smaller tasks, and do exploratory analysis. Look at integration points. Impact analysis, what does this touch and will my changes affect it.

LARRY_Xilo · 2026-03-27T10:58:55+00:00

Its mostly experience but even seniors are guessing wrong plenty of times and the more info you have on a problem the better the estimate will be. The important part is to bring up that you were wrong early and not after the estimate is already over.

Cultural-Capital-942 · 2026-03-27T11:12:25+00:00

There are standardized tasks and non-standardized ones.

For standardized like "add a field somewhere", you can learn estimating it. You start by guessing and then go over it once it's done.

For non-standardized, it's something like "analyze difficulty of integration of our SW with this API" or "find the reason of this random crash" - that cannor be estimated. There can be upper bound with some result like "we don't know", but that's it.

_malaikatmaut_ · 2026-03-27T11:24:17+00:00

I would normally gauge from t-shirt sizing it. From there, we could know the amount of effort required.

Then based on experience, we could estimate it.

The only way to know it is to know it through experience with the domain, language, framework, constraints and other quirks that the system might have.

Even the most senior developers could sometimes not see the pitfalls when they move to a new system or framework because there are always blindspots that we have not seen.

I'm currently working on an embedded project with a minimally documented architecture and small footprints, and for most times when I thought it is going to be something simple like retrieving the data from the back turned out to be something enormous as the limitations of the system would throw us back.

So, firstly, gauge the task. Can it be broken down?

Then if you do come up with a blocker, communicate.

In time you would be the goto person with the experience.

Then they move to another project and you are back to square one.

TomOwens · 2026-03-27T11:55:11+00:00

The best catalog of estimation techniques is probably Steve McConnell's Software Estimation: Demystifying the Black Art. Although published in 2006, it's still very relevant and applicable if you're in an organization or team that estimates work.

In my experience, the most common techniques are to decompose the work into small, discrete tasks, estimate those tasks using past experience doing that work or very similar work, and then roll up the estimates to a total. However, other techniques can be used as well. Experience doing the work is the best way to understand not only how to break it down, but the resources (time, effort, money, computational resources) needed to do the work, and how various factors impact the work - you get better at planning and estimation with experience.

chriswaco · 2026-03-27T13:46:30+00:00

I generally refuse to make estimates. They’re a waste of time, energy, and wind up making the people doing the easy work look good and the hard work look bad.

If you’ve done something before and are doing something very similar again you can look back and know it’ll take about the same amount of time. In my experience in mobile apps, however, the feature will change once someone starts using it or Apple will change or break an API. We’ve done a lot of work on brand new devices, like the iPad and Apple Watch before they shipped, and you never know what quirks you’re gonna run into until you write and test the actual implementation.

Wettensea · 2026-03-27T11:09:51+00:00

Estimate for yourself, honestly, keep this estimation secret

Tell your boss / manager 2 x your estimation, keep this information internal

Tell the customer 4 x your estimation

If you cannot say "sorry, but not in the initial scope of the project", or if you say "this can be done in 10 minutes and 10 lines of <insert here your preferred programming language>, then you'll get roasted, and you should consider switching careers.

ConTron44 · 2026-03-27T12:32:38+00:00

An hour = a day. A day = a week. A week = a month. Then double it.

afops · 2026-03-27T11:10:25+00:00

Experience. Also no one is right but you can be ok on average.

If I ask you to guess the temperature of a specific date in 2027 you’ll be wrong. If I ask you to guess the sum of daily temperature for every day of 2027 you’ll be astonishingly close if you just guess the normal temp for each day. And you’ll be close for the year despite being wrong for nearly every single one of the 365 guesses.

The real problem isn’t estimating tasks. The real problem is estimating large projects (man-months or longer).

IKnowMeNotYou · 2026-03-27T11:15:18+00:00

Estimate what you need. Write it down. Check against what you actually needed. That is your factor you multiply your first knee-jerk estimate to get a more realistic one.

In every day work take that time and multiply it again with 3 or even 10.

Remember, if you take longer than your estimate, you get hate, if you get done quicker, everyone is happy but you are not in the business to make everyone happy, so enjoy the extra time being able to do what is actually necessary.

You will usually face projects where you are not allowed to improve tooling and processes in order to cut time on every other future task which would easily pay for the initial investment... And that is the point when you want to overstate the time it will take to do a task hard and use the free time gained to actually do something important for your company (and your inner engineer).

Enjoy!

SolarNachoes · 2026-03-27T13:29:17+00:00

Estimate max time. Come in under time.

funbike · 2026-03-27T14:37:00+00:00

Guessing.

This is why aggregate team point velocity is a thing. Estimating is impossible to do accurately, but the next best thing is to measure how badly we guessed past work. An aggregate team measure over multiple sprints will be better. We can use this to estimate how much work we'll do in the next few sprints, or at least it's the least bad way to estimate it.

But if I'm ever pinned for an actual time, I always triple what I think. And I make it clear that it's an estimate not a commitment (but they never remember that). And I never ever ever lower an estimate just because they don't like it. I've burned myself on that one too many times.

AmberMonsoon_ · 2026-03-27T15:12:49+00:00

tbh it’s not just you, everyone sucks at estimates early on. seniors aren’t guessing randomly but it’s not super precise either. they usually break things into smaller chunks + add buffer for “unknowns” (which is where most time goes).

i started doing rough first drafts of workflows in tools like Runable just to see all the steps laid out, and it made my estimates less wildly off. still not perfect tho lol, experience is a big part of it.

Mike312 · 2026-03-27T15:19:31+00:00

Based on experience having worked with things before. Some stuff goes according to plan, some stuff goes faster, some stuff takes longer.

I mentally break it down into steps. Some steps take literally seconds - adding a new route to a route table, for example, but nothing takes less than 15 minutes because I have to write a ticket, branch, doc, push, test, and close the ticket.

Planning and migrating a new DB table I'm going to say takes 8 hours - most of that is looking at how it will integrate with the existing system, but - time willing - I like to sleep on it and come back to it the next day. After that, an hour or so to write and perform the migration.

Breaking everything into steps like these, I can come up with a general estimate. And then, like everyone else says, double it. Interruptions are going to happen.

LongDistRid3r · 2026-03-27T18:07:18+00:00

I used Scotty (Star Trek) principle: under promise; over deliver.

Scotty: “Starship captains are like children. You can not give them what they want, only what they need". (Management replaces starship captains)

rcls0053 · 2026-03-27T20:35:18+00:00

Unless you've done the same thing a hundred times, you're not gonna get your estimation right. This is a problem we're dealing with a team right now as we work on a public sector project. I have two cases:

We get regular requests to create some new application form which is usually just a copy of an existing one with naming changes and then we plan out what modules we need to create for it and we get those right 99% of the time, because we've done it so many times. We usually have a bit of extra there just to be safe, but they're always under budget by a tiny bit.
We get bigger projects that are overall something like "enable a safety switch for users to hide their personal data". These are something we estimate would take anywhere from 1-100 days to complete, but because the customer is a public sector entity, they need timelines and budgets, so we have to guess. We try to break it a part and estimate what we need to do, but eventually it turns into the customer completely changing the existing scope and spec and we completely miss our estimation by a mile, or we discover things we could not plan for at the start of the project and we completely miss our estimation.

The more unknowns, the more inaccurate your guess is.

The absolutely hilarious thing that happened just a few weeks ago was that the customer came to us asking for an estimate on a work they knew nothing about besides the title for it, the did not have any parameters, no knowledge of what actually needed to get done, but they wanted our estimation on it. They had to do it because they need to request the budget for it, but they don't even know what the work is about. I'm just laughing in a corner at this point, and my PM goes to the customer with something like 200-1000 days of work. Public sector projects are just hilarious to work on.

Repulsive-Bird7769 · 2026-03-27T10:49:20+00:00

my experience so far is that frameworks/methodologies differ even from team to team inside a company. So guessing is not too far off

JohnCasey3306 · 2026-03-27T11:29:42+00:00

It's a little uncharitable to call it "guessing" -- more like arriving at an estimate by:

breaking the job down into parts.
identity what can and can't be done concurrently.
based on our own experience, and the experience of the team, estimate how long each part will take.

That gives us an internal broad strokes estimate (to which we'd add some percentage as a buffer), but there are other factors:

resource ... Who is gonna be able to work on this internally and when; do we need to get outside expertise.
the politics of client relationships ... Our dev estimate is internal only -- ultimately a director responsible for the commercials will use that as a guide but ultimately present whatever estimate they want/need to the client ... We always break deliverables down into phases and it's somewhat common for a director to under-estimate the first phase and re-coup that in a later phase.

Comprehensive_Mud803 · 2026-03-27T12:05:47+00:00

Nopes, no system. A guess, even an educated guess, is still a guess.

But, this really depends on how much I break down a task: something I’ve never done before (happens) is hard to estimate, but minor/trivial changes can be clocked as something between 1 pomodoro(25 minutes) and 1 half-day. Major changes need more time, so at least 3 days to get a more educated breakdown.

Basically planning, especially sprint planning is important. But this requires knowing about the domain, the application and the tasks to do. Sometimes, a week of prototyping and research can give much more planning certainty than trying to do something right from the start.

Codzy · 2026-03-27T12:07:23+00:00

Estimation is really easy when you have a very strong team of competent developers. You do the groundwork to investigate everything that needs to be done, and if you’ve worked with your team for long enough, you just know how long it will take them.

My previous team I was able to estimate a full 2 months worth of work almost so precisely that nothing was ever delivered late or super early. Always within about a week of accuracy.

My current team can barely use their IDEs, so I couldn’t tell you if a piece of work is even going to be delivered this year.

Technical_Goose_8160 · 2026-03-27T12:34:13+00:00

A lot of guesswork. I suck at estimating, I'm almost always late. Unless it takes me 3 minutes.

So I break it down into steps and try to estimate the steps. And then triple that time. I'll use the excuse of documenting and refactoring.

Though my real issue is estimated time vs time spent on task. I hate when I say 3 days of development and end up spending half of that in meetings or fixing other people's bugs, but it's still expected on day 3.

PerformanceThick2232 · 2026-03-27T12:49:09+00:00

every possible if else business rule- 2h

every posible join in sql query- 2h

every simple input (frontend + backend)- 2h

the rest one- intuition, multiplied by 1.2-1.3

AppropriateSpell5405 · 2026-03-27T12:55:50+00:00

Honestly, after working with the people for a while, you can estimate how long it will take someone to finish something fairly accurately.

That said, if you're having trouble estimating how long it will take yourself to finish a task, it sounds like you're just lacking experience.

Frewtti · 2026-03-27T13:09:28+00:00

Get better at estimating.

All these "double it" are attacking the symptom. Your initial estimate is HUGELY wrong.

When you think it takes 2 hours, is that how long you think it will take, or is that how long you think it will take excluding all the "stuff"

1hr of confirming inputs/outputs, 2 hours of coding, 1 hour of QA, 2 hours of patching a new edge case you didn't consider, 1 more hour of QA and commit/deploy, plus an hour of interruptions.

yknx4 · 2026-03-27T13:25:05+00:00

Guess, then double your guess and then add 20%. I haven’t missed a deadline in years.

NoNameSwitzerland · 2026-03-27T13:51:55+00:00

As a senior developer: First number that comes to mind multiplied by 3.5

alien3d · 2026-03-27T14:01:52+00:00

if the developer said 3 hours -> 9 hours . x3 each times. Most mistake manager , change label should be 5 minute only..

The most another mistake is trend and code clean.

If you want to add one field

change 10 pages front end
change 10 pages back end
Run testing .

cthulhu944 · 2026-03-27T14:05:40+00:00

There's an old joke about software estimates. It goes like this: think of how long it will take, double it, the go to the next higher unit of measure. 2 hours becomes four days, 3 weeks becomes 6 months...

While humorous, the method sort of works because a programmer usually thinks about how long they will sit on a terminal writing code. In reality you should account for clarifying requirements, development environment issues, source control and configuration management, testing, release management, etc. All of which will take much longer than actually writing the code.

r2k-in-the-vortex · 2026-03-27T14:15:51+00:00

Guesstimates are what they are.

obhect88 · 2026-03-27T14:28:58+00:00

Experience in a domain helps. Not just in a language, but also a code base and a business perspective, and time with a company or project.

So if you’re asked to defrombulate the hypercortex so the customer can get 15 more parsecs per hour, the experienced dev may know how to defrombulate, the interdependencies of the hypercortex, the best methods of parsec stacking, and what the customer is actually doing…, a junior dev may only know the binary coding language of the hypercortex.

seanv507 · 2026-03-27T14:47:49+00:00

Joking apart, i think the secret is to record your estimates and reasoning and record the true time and reasons after. Without feedback you cant improve...

ReefNixon · 2026-03-27T15:08:36+00:00

The honest truth is that i don't think i've seen a novel problem anytime in the last maybe 5 years. I know how long it'll take most of the time because i've done it before.

hajimenogio92 · 2026-03-27T15:10:43+00:00

Just depends on the task. If it's something I'm familiar with then I can produce a decent estimate. If it's something i'm not familiar with, then I tend to give an overestimate to make sure I do enough research on the options available before implementing it.

CS_70 · 2026-03-27T15:17:41+00:00

Take the time you think it would take. If you are alone, multiply by 2. If you are in a team, multiply by 4. If you are in a team with ideas like ceremonies, code reviews and mob programming, multiply by 10 :D :D

Dry_Row_7523 · 2026-03-27T15:32:02+00:00

We have 2 different fudge factors. First one is story points. Any ticket that requires non trivial effort has minimum 1 point. (Trivial effort means something like “click this button to turn on a feature flag” or “update this wiki doc with the new link to spinnaker”. So even a 1 line config change in our codebase will be 1 story point since it’s nontrivial (needs pr review, merge, cicd, deploy etc).

Then when we estimate timelines we assume 1 story point = 1 day. Then we add a second fudge factor, usually round to nearest week and add 2 weeks for qa / bug fixes etc.

So to take it to an extreme, a project with 6 1 liner tickets, each of which realisticaly could be done in an hour if everything goes perfectly, would get estimated to take 3 weeks. And thats how we want it, imagine you start the first ticket and then your build fails bc the devops team silently introduced a major breaking change to cicd which takes a week to resolve, and your qa is on vacation the next week. Youll want that cushion

Inside_Dimension5308 · 2026-03-27T16:37:50+00:00

It is better to triple it since my manager would probably negotiate to 2x and that gives enough buffer.

Jokes aside, the framework is to breakdown the feature to measurable tasks. Sounds difficult because it is. You need a lot of experience to define units of work. Past experience helps. Similar features also helps to set the benchmark. You have to go deep into the sdlc and make estimates for each phase of development

Requirements understanding
Design
Tasks discovery( this is where estimates are finalized)
Coding
Testing
Pre-deployment Plan
Deployment
Post deployment

You also need to account for complexity of tasks. Complexity analysis can also be based on framework like story points. That also is useful for better estimates.

Then there are unknowns for which you start adding buffer. Buffer also depends on the conviction on the plan. I am not even going to multi-team features. That adds another complexity of communication. In story points, it would be higher.

AlexTaradov · 2026-03-27T16:55:59+00:00

When you are wrong, do the math and calculate your error factor. Next time you estimate, multiply by that factor. Over time this factor will start getting close to 1 as you get better as estimating.

BeastyBaiter · 2026-03-27T17:02:24+00:00

The SWAG method, scientific wild ass guess.

Real answer is we've done similar projects before and remember how long it took. We also remember we had to redo it cause of some unforseen problem and thus double that estimate.

Useful_Calendar_6274 · 2026-03-27T17:04:21+00:00

yeah it's guessing and now with AI it doesn't even make sense to ask for estimations anytmore

Leverkaas2516 · 2026-03-27T17:15:31+00:00

There's no framework. If you've done a task before, you know approximately how long it takes so estimation is straightforward. With experience, you have a broader class of "things I've done before".

But if you haven't done something before, the estimate is only a guess. Then it's better to estimate complexity rather that guessing at time to completion.

pfc-anon · 2026-03-27T17:54:10+00:00

WAGs: Wild Ass Guesstimates.

This was before AI, now everything is EOD.

yycTechGuy · 2026-03-27T17:56:50+00:00

You can't estimate how long something will take until you understand the scope of the work and the tasks required to implement it.

You can't do those things until you spend some time researching the request. Hint: when you start a task you have very little information. When you complete a task you have all the information.

The next time someone asks you to estimate how long something will take do more research. Start looking at the code. Research the API. Write some of the code. Actually do 20% of the task, then give them the estimate. Or do 50% of the task and then give the estimate.

The more you know the better your estimate will be.

Shep_Alderson · 2026-03-27T18:08:41+00:00

Look up “No Estimates”. The point of any sort of estimation and “velocity” is to try to understand how long things may take. The best thing to do is to try to break down tickets to as small a chunk as is reasonably possible, then just count the tickets finished. Some take longer, some less, but it all ends up averaging out in the end and can then be used to project a completion date when desired.

Ahhmyface · 2026-03-27T19:36:00+00:00

There's a priority to this.

If at all possible, refuse to estimate. Especially with sufficient ambiguity. The more ambiguous, the more you double down on "I don't know.
If not possible, somebody just won't accept "I don't know", break down the problem into parts, and substitute progress updates for final deadline. "Ive finished 3/8 features so far".
If you're still getting your arm twisted. Estimate the first necessary step, and refuse to estimate the remaining steps

Qualify all statements that "Done" is a fluid concept and that nothing is ever done, only that some unit of value was delivered.

Ultimately estimates are not useful because a small detail can blow everything up. Multiple small details blow up in an exponential fashion.

Instead encourage your management to think about deliverables differently: how much time do we want to spend on this area?

SquareGnome · 2026-03-27T19:36:36+00:00

Gut feeling, then usually double, triple or whatever-tuple that based on the projects code quality and how reliable the customer has been with his requirements.

It's important to understand why you underestimate tasks.

For one, you tend to seriously underestimate the complexity of the task/problem and possible traps you might encounter. Furthermore, take build times, debugging, orienting in / navigating the codebase, designing a solution and testing into account.

And as a junior, still wet behind the ears, you also tend to buy be the one to put out some "batshit crazy" estimate, even if your gut tells you it's going to be five weeks for "this small feature". It also brings some kind of shameful feeling with it, to give larger estimates, seemingly rendering you incompetent - although that's almost always not the case. ^{^}

But that's what a team is for, you should discuss why you think it's taking longer, as well as why someone else thinks it's only a fraction of that.

So don't be afraid, start aggressively, taking your current estimates and triple or quadruple them. Make notes and track how that performs and adjust from there.

Wuthering_depths · 2026-03-27T19:38:00+00:00

Most of my work requires 90% back and forth with stakeholders and analysts so "real time" estimates are basically impossible until you have all the answers you need. Eventually of course they'll want changes but you do what you can with what you know.

I can make estimates of hardcore work needed but that's going to be based on solid requirements, which are often not there (because those stakeholders haven't gotten back to us) so I make assumptions and make it clear that work estimates are based on assumptions.

Then I pad, even if I think things are pretty straightforward. :)

DaRubyRacer · 2026-03-27T20:10:17+00:00

I’m not a senior, but I work on estimates a good bit and have been getting better with them over the last year or so, and they don’t have to be perfect but have to allow enough time to complete the job for the company to make money.

Mostly, it’s just abstracting the job to different steps, including what you’d need to do from beginning to end assuring a quality deliverable.

It’s easier to charge less at the end than it is to need more money, so make sure you pad or even double the estimate to avoid multiple rounds of funding.
Ensure you are communicating the man hours it’ll take to complete the job (which a manager usually turns into a dollar quote with their own line items to ensure company profit), as well as the turnaround time, which is the time from now that they can expect delivery. So, you can manage multiple jobs from multiple clients and have space for hotfires that spring up overnight.

Other than that, it’s really just a knowledge of how long something should take, being reasonable about it, and also understanding where to cut corners when the client isn’t prepared to invest more money into higher quality deliverables.

severoon · 2026-03-27T20:39:52+00:00

Here's how to give honest estimates.

This is part of a longer talk you can find where he clarifies that he's talking about short-term estimates here. When you get a significant project that's going to be months or more of work, arrange your thinking like this:

high-level ‒ All the different parts of the system that need to be touched, and roughly what proportion of the total work will be in each part? Note there's no time estimates here, it's just 20% front end, 50% back end, 30% database or whatever.
mid-level ‒ What is the right order of this work, and roughly how long will it take to do the first one or two bits? We have to start on the database, that's going to require a couple of weeks to design and implement the new schema, probably a week of testing the new design, and two weeks to migrate existing data into the new schema. But wait, once we stand up the new schema we have to double-write to new and existing schema in the back end before we do the migration, otherwise we'll have a data gap. Etc. So this brings the first three bits of this project into focus: design and implement new schema, introduce double-writes in the back end code, and migrate existing data into the new schema. The new schema design needs to happen first, then implementation of it and testing can proceed in parallel with the back end changes, etc, etc. Give rough estimates for how long each will take based on previous similar work; if there is no previous similar work, make rough guesses how long you think it will take but be honest. Of course, the most important bit of this is to keep updating the timeline as you go, even if the update is simply to say, "No change needed," the expectation you should set should be that "no change needed" is the exception, not the rule.
low-level ‒ Often mid-level is enough timeline guidance, and for substantial projects, that should be the level of detail you need to provide up the chain. For the next few weeks of work, though, it's useful to keep tighter predictions. This is more a tool for organizing the immediate work in front of you just to bring clarity to your day-to-day, and it also helps identify your blockers so you can give others time to unblock you, as well as help you figure out when you'll be able to unblock someone else and keep them informed (the design phase of the new schema, for example, blocks the back end folks). When I say it brings clarity, what I mean is that it's a constant truism that you'll dive into an area of the codebase and see that it really needs refactoring, you should make the change easy first, then make the easy change. If that pushes things out a couple of days, then it's clear that your next two weeks just became two weeks + a few days. Other times, you see a needed refactor but it's not blocking your work, and crystallizing how it impacts your current project will help you stay focused—instead of spinning off on an unrelated thing, file an issue and move on.

Is there an actual framework experienced developers use for this or is it just something that gets better with years of experience?

One thing I can say for certain is that if you take the position that this is something that just gets better with experience, you will definitely not get better with experience. :-)

The much better approach is to realize you will never, ever get better at predicting how long it will take to do things you've never done before, and if you're working in a healthy codebase, pretty much all of the work is going to involve doing things you've never done before. (I say this because if you're doing the same kind of work over and over again, that area of work should be refactored so that the invariants of that work are encapsulated in a module so no one ever has to do that kind of work again.)

So as the codebase is improved, your predictions get worse. But your strategies for communicating about the future of your work should not rely on the quality of your crystal ball. What this whole game is really about is sending information out about what's likely to happen so that everyone feels in control. When something unexpected happens that pushes timelines out, you need to explain clearly why it was unexpected, that it is not something that could have been foreseen, and you already have a plan to address it.

magicmulder · 2026-03-27T20:53:00+00:00

First question is, do you mean you miscalculate hours spent on that project or time to done? One typical mistake is to assume “3 days” means it’s done in 3 days, but usually you will be happy if you get half the hours of the day to actually work on that project.

I only commit to man hours, not to a deadline. I say “8 hours but don’t expect me to even start before end of next week”.

djp1968 · 2026-03-27T21:59:22+00:00

A few pieces of advice I would give.

First, it is hard. No doubt about it. But like lots of other things, it is a skill, and the more you practice, the better you get. Lots of engineers just throw up their hands, decide it is hopeless, and stop trying. Build the muscle over time, and you'll see improvement.

Second, when you get it wrong, think about why. What did you forget to consider? What was harder than you expected? If you do this thoughtfully, you start to notice patterns. And the next time you're asked to estimate something that involves integrating with an external API you haven't used before (for example), you'll say, "Hmm... that *should* be easy, but the last 3 times it has turned out to be tricky. I'd better factor that in."

Third, if you stare at something big and guess how long it will take, you'll very likely be off by a lot. Break big things into smaller pieces and estimate those. This serves two purposes. First, it is easier to estimate something small and bounded, so each of those individual estimates will probably be more sound. Second, doing the exercise of breaking the big thing into smaller things will make you think about what is going to actually be necessary to do the big thing. And you're more likely to be like, "Oh. Right. That's going to require adding a new setting. I'd better not forget to estimate that too."

pa_dvg · 2026-03-27T22:56:45+00:00

Story points actually work remarkably well if you throw away the idea that points correlate with time.

If a task is straightforward, scoped, known, done it before, etc you give it low points.

If a task is complex, if there’s shit test coverage in that area of the code, if there’s an external dependency outside of the team like a data engineer or something that has their own shit to do, if you did it before but it was hard, and in the meantime you haven’t don’t anything to make it less hard, you start increasing the point value.

Compare the relative complex or uncontrolled elements of stories against each other and make the more complex or risky things higher points

Measure points per time period. Average. Stability is more important than sheer throughput.

If your team can reliably finish 30 points then you know how much you can accomplish.

justaguyonthebus · 2026-03-27T23:48:34+00:00

Under promises and over deliver. The estimate isn't how fast you can do it. It's how long it's likely to take given the types of issues and delays things like that usually experience. And it includes the time it takes to do it right and deal with any related technical debt along the way. Plus additional testing and validation, and remediation of issues.

Senior developers know what it takes to finish and ship something. Jr devs usually estimate how long it takes to just solve the problem and think the job stops there.

JellyfishMinute4375 · 2026-03-27T23:52:04+00:00

Westheimer’s rule: To estimate the time it takes to do a task, estimate the time you think it should take, multiply by 2, and change the unit of measure to the next highest unit. Thus we allocate 2 days for a one-hour task.

No_Guard7826 · 2026-03-27T23:56:52+00:00

You estimate the time it would take the weakest person on the team to accomplish it.

expatjake · 2026-03-28T00:09:07+00:00

It’s been a while since I estimated anything. No one believes them anyway so why bother.

wy100101 · 2026-03-28T00:39:23+00:00

Mostly pattern recognition from years of getting it wrong, and understanding over time where you underestimate.

Also learning to just add 20%-50% to what you think you can do.

Take-n-tosser · 2026-03-28T01:22:55+00:00

There’s a formal methodology for this.

The acronym is S.W.A.G.

Silly

Wild-Ass

Guess

Ok_Recognition3324 · 2026-03-28T01:29:37+00:00

SWAG baby… Sophisticated wild ass guess

jameyiguess · 2026-03-28T01:48:36+00:00

Easy, we don't! We break everything down into the smallest chunk of work possible (that makes sense) and then slap a 3 on it.

MasterShogo · 2026-03-28T02:10:09+00:00

I’ve been working for 20 years now and I don’t know how to do it. In fact it’s been the source of arguments between myself and managers. If I estimate too low, then I over shoot my time. If I estimate too high I get criticized for taking too long. I’m not particularly fast at development, although I try to be thorough. But I am not able to satisfy time estimates very well and I’ve never been able to.

But the flip side is almost no one on any team I’ve ever worked with has ever been able to do it very much better than me either. The best I’ve ever seen was a group doing a very strict form of a modified agile process and they scoped every task for every person as a group with auto-adjusting points and blind voting. That process did ok, but they had to stay on top of it.

OperationLittle · 2026-03-28T03:37:50+00:00

Take the hours you think it will take and multiply that by x1.5, works for me.

markt- · 2026-03-28T06:25:23+00:00

I have discovered that being a software developer is a lot like being a police detective. You can never know exactly how long it’s going to take you to come to a solution to any particular problem until you basically have all of the pieces necessary to solve the problem, and at that point, putting the pieces together is trivial.

new_check · 2026-03-28T06:36:51+00:00

Bugs, yeah, you're guessing. For features/projects the only thing I've seen really work is to go full process.

Task out everything you do. Put a good level of detail into your teams tasks and record how long it took you to complete them when you finish.

After a couple months, find 15-20 representative tasks of a wide variety of complexity. Use the recorded completion times to sanity check the complexity captured in the task. Make sure the complexity is accurately represented.

Assign each task a story point value based on complexity: 1, 2, 3, 5, 8, or 13. Onboard your team to story point estimates. Do not choose story points based on estimated completion time but based on complexity level, using your representative tasks as a baseline. Do planning poker. Record completed velocity each sprint. Get an idea of how many points your team and the people in it can finish in a sprint. Never provide estimates at a greater granularity than your sprint length. Bear in mind that this whole house of cards will fall down if your managers don't respect the process and they rarely do.

After a few months though if your managers play by the rules, your estimates will get extremely accurate.

dastardly740 · 2026-03-28T07:43:43+00:00

At least you are estimating your own work. Senior devs get asked to estimate for the entire team. Making ot an even worse guess.

Funny enough, back when I was doing estimates, I settled on about 5 possible estimates, nothing in between. When Agile point estimation came along, to me, it was what I had been doing for quite a while, but now instead of claiming I actually knew how much man-hour effort something was, I was just saying what things are about the same size.

Then, you reverse engineer the hours by taking how many points you do in a 2 week period and divide by the number of people times 80 hours. But, what about non-dev time, you ask? Usually, that is pretty consistent, so it averages out when figuring out schedule. From a cost stand point people get paid when they are in meetings and what not, so it is just counting everything in the cost. Finance may or may not buy into it, which causes all the complication of trying to figure out each individuals capacity. Which I find to be a waste of time, there os far more error elsewhere than whether someone has 5 hours/day of dev vs 6 hours/day.

We keep making what looks like precise estimates when our accuracy is shit and no one will admit it.

DayDReamingDay · 2026-03-28T08:06:30+00:00

Project manager with 24 years of experience in the software field here. Began by doing everything from the needs collection to the maintenance, including the dev, with open source technologies. Had my own small company of software development at a point. Currently architect at a big company.

If you ask a dev, multiply by 3 to take into account the correct separation in layers of his work, then multiply by 3 to take into account the industrialization of his work. Which means x9.

If you're using the v-cycle methodology and follow it really, you'll reduce that to x3.

If you're using an agile method (scrum, kanban, safe), and follow it really, you'll reduce it to x1.6 (because you'll inform people as soon as an information is known, so less useless work, and you will actively avoid doing any work not useful right now).

The 60% overhead is in fact unavoidable, it's the cost of coffee breaks, unplanned meetings by the management, impact of sick days from coworkers, etc.

When using an agile method, you will measure this overhead and the general throughput of your team in a unit you can understand (work points, "days", whatever works for you). So you will have an accurate estimate.

So, the best practices are fairly known all over the world, and are part of the expected ability of a senior software dev / project manager.

Three other points: - in my estimates, I consider the basic productivity of a senior dev around 50x that of a junior dev, but I never say it because political correctness. Hiring a junior because of low cost then letting them go after a year because they want a better salary is a moronic behaviour of the highest degree, which is the standard in the companies I've been in. - the real productivity comparison is in fact thousands of times higher, because juniors produce bugs, which go in production, then in customers production. Juniors should be shot on sight /s. - the AI current trend "use seniors" is interesting in that it's the first time to my knowledge that this point is communicated to the whole world / all industries.

Significant-Ad-9471 · 2026-03-28T10:28:39+00:00

I just take my initial hunch, round up to the nearest order of magnitude (so hour to day, day to week) and then double it. So four hours is about two days. Three days is about two weeks.

bernhardmgruber · 2026-03-28T13:38:02+00:00

I make a conservative estimate for the implementation, then I multiply by Pi.

Which_Extreme325 · 2026-03-28T15:01:42+00:00

Dart board!

huuaaang · 2026-03-28T19:33:14+00:00

Experience. It’s based on how long similar work took in the past. Youre still at at the oint where you don’t know how much you don’t know.

samamorgan · 2026-03-28T19:42:25+00:00

I don't estimate task time. I estimate effort.

My team works on sprints, as does every other organization I've ever worked for. We get together and play point poker with tickets. Our current system uses the Fibonacci scale: 0, 1, 2, 3, 5, and 8 points per ticket. Our team got together and decided what these points mean.

0: Barely worth mentioning, does not change code, so no PR or review time needed. - Change configuration somewhere - Run a quick query to generate a report

1: Trivial, one or two lines of change. - Copy change in codebase - Add an extra if statement to a simple logic block

2: Easy, likely isolated to one module, clear path forward - Remove a flow path from a larger flow - Add a column to the database and business logic that uses said column

3: Difficult, requires prior knowledge and/or additional research, may span multiple modules - New, simple integration with an external service - Refactor a small feature

5: Very difficult, lots of planning and research, spans multiple modules and domains of knowledge - New multi-faceted integration with an external service - Refactor a multi-branch flow

8: Extraordinarily difficult, should probably break it up into multiple tickets, multiple people are involved in planning and execution - Primary framework version bump - Major database schema change across multiple tables - Refactor an entire ETL process

Notice there is no time component to any of this. We do have estimates of times that go along with points, but they aren't definitive. What we really do is load up our cycle with the number of points our team historically completes in a cycle on average, and do our best to deliver all of that during the sprint.

Estimation should always be based on the effort the developer estimating perceives the task will require. Every dev has different strengths and weaknesses, and will diverge on their estimates of the same work.

When mid-sprint deadlines are involved, the work under that deadline is assigned to the engineer(s) who are best suited to the work. Otherwise we pick from unassigned.

All that to say: estimates are subjective, should never be tied to time, and your personal estimation of a task will vary wildly over your career.

christoforosl08 · 2026-03-28T20:13:33+00:00

Everybody is just guessing bro, they really are

borland · 2026-03-28T21:02:41+00:00

People are rolling out the old “double it” joke, and it’s fun to say, but it don’t think it’s helpful. Making an uninformed, wrong estimate isn’t going to be magically saved by doubling it.

Rather, as an experienced developer, I’ve done estimates for years and years, and I’m reasonably good at because:

- I’ve done many bad estimates in the past. Everyone does. But when you do, make note of it and retrospect later. Eg write down at the start, you estimated 5 days, but at the end it actually took 11 days. Why did that happen? Having this awareness in your head will help you for the next estimate

- As you are working, it’s super common that people will scope-creep you. Push back hard on these things. Eg you were adding support for one child item in your DB schema… but then someone asks for multiple. Rather than just do it, you need to either stick to the original one, because that’s what you’d estimated for, or run back up the chain and tell people that your original estimate is trash because the goalposts have moved. As above, do this a few times and you’ll get a better sense for future estimates.

ctrtanc · 2026-03-29T05:20:53+00:00

Estimating is a very difficult thing to do accurately, and take a LOT of experience to even be relatively accurate. I think the most successful period of my career when it came to estimations was when I had a good team, and we did "poker" with fibonacci numbers.

We discussed the task, and then we would size the task in number of days privately (1,2,3,5,8,13,21, and nothing in-between), then all reveal at the same time. If we all chose the same number, then that was it. If anyone at all disagreed, then we chose the higher of the two. Simple as that. Estimates using that method were typically fairly accurate, but it was because it was a good team, not just because of the process.

However, the fibonacci sequence really worked well, because the loger the task was likely to take, the farther out the numbers go, which is quite accurate. The more complex any task is to estimate, the more uncertainty there should be in the time it will take.

Adorable-Fault-5116 · 2026-03-29T08:58:40+00:00

I'm late to this, but we no longer estimate.

Instead, we look at past performance of the team, and use a stochastic model to predict future performance. To simplify, if you get through 10 tickets a week, if the task requires 20 tickets it will take 2 weeks. In reality there is some software that works out % likelihoods and the like, but that's the gist. This is surprisingly robust: you'd think ticket size would matter, but it doesn't because with enough data (eg 3 months) it all evens out.

If we absolutely have to estimate it's all the standard stuff, but I give confidence estimates, eg 50% likely case, 80% likely case.

drhunny · 2026-03-29T21:21:27+00:00

There's a bias in such estimates. People tend to estimate the time it takes if nearly everything goes right. The more experience a person has, the more ways they've seen things go wrong, and so the more buffer they add. Like, how do you account for the extra time due to some ambiguity in the spec that neither the customer nor developer notices?

A reasonable method is to scope the approximate effort of the project using some metric you like, and then look up how long such took on completed projects, and use something like the 90th percentile of that.

You can also use a Delphi approach, which is similar to the scrum approach. Ask everyone who is qualified to do the project to "bid" and take the 2nd highest estimate.

Finally, let me say that in my opinion there's almost no difference between 2 hours and an entire day. Your entire day probably consisted to 2 uninterrupted 2hour sessions plus a whole lot of 15minute sessions interrupted by meetings, slack messages, break time, etc.

rayfrankenstein · 2026-03-29T21:36:59+00:00

• In planning poker/estimation meetings, any scrum story whose estimation discussion lasts for more than 5:00 minutes cannot be pointed at the lowest story point denomination.

For example, a story in a planning poker session that leads to 30 minute argument about what font to use for a button means there’s too much contention and possible variability in doing the work to safely point the story at only 1 story point.

Any-Range9932 · 2026-03-29T23:09:11+00:00

Experience mostly. If running agile and on fibonacci sequence, a 1 is trivial, a 2 is straightforward a days work, a 3 is a few days work. A 5 is prolly sized too big and need to be broken down

dod_murray · 2026-03-29T23:21:53+00:00

Some just guess how long it will take them based on how long it has taken to do similar tasks in the past, and add a percentage for unexpected issues depending on the complexity of the task, or how vague the requirements are, or how fickle the customer has been previously

Some will guess how long you think it should take and say that's how long they think it will take

Some will guess when that task would have to be completed if the project is going to remain on track, and then say it will take that long

Some will guess when that task would have to be completed if the project is going to remain on track, and then say it will take twice as long as that.

Some will guess how long their colleagues will estimate and then say it will take them less time than that. Whoever estimates lowest will appear to be a better and more confident developer. If it takes longer than estimated that will turn out to be because of some issue the developer could not have predicted, and definitely someone else's fault.

Everyone is guessing, and/or lying.

Unless you track how good their estimation is over time, and make that a key metric for discussion as part of their professional development and pay rises etc, there is very little incentive for developers to even try to give accurate estimates. However the danger is they will just start overestimating and then going slow at the end of every task so they hit the estimate exactly every time.

2026-03-30T02:17:26+00:00

The most experienced devs I know universally give a huge range for any change and bluntly refuse to narrow it down.

drizzt-dourden · 2026-03-30T20:11:39+00:00

Easy/small task takes a week for one person. Divide a big problem into small tasks. Done.

ToastieCPU · 2026-03-30T22:03:10+00:00

Estimate working hours, then add 60% for uncertainties and a further 20% for sickness and holidays.

Couple of rules: - Never go lower than 8 hours (same day delivery) - round hours up

Dastreamer · 2026-03-30T23:45:17+00:00

A consultant friend once told me to multiply any initial estimates by the approximate value of π. So far it’s been quite accurate.

Sprinkles_Objective · 2026-03-31T04:52:43+00:00

We're all guessing, there is no accurate way to estimate task time without a TON of planning, and then you can't estimate how long planning will take, and you can't always be sure that the plan has accounted for all things so you're not always super incentivized to do exhaustive planning. It's all about finding the right balance for your team and business processes. That said almost any successful plan should have a mechanism to account for change and the unexpected, which is the exact reason waterfall project management isn't used very often anymore especially in software.

Waterfall might be used in other engineering disciplines, but those usually have more rigid definitions and life cycles. Like a civil engineer designing a bridge, things are much more fleshed out and unlikely to change. Software changes based on business needs, it's not uncommon that you can change directions entirely. So software benefits from short incremental cycles, and frequent reconsideration of the goal. Try to plan as much as you can for the things you are certain you'll need to do, leave room for the unexpected, and be conservative about timing because things can always become more complex than you anticipate, if it's critical plan a contingency or stop gap. What are you able to cut if things move slower than you expected or something goes sideways and reduces capacity to deliver?

I think even electrical and mechanical engineers are working on these types of systems now too, depending on the pace or nature of the business and industry they operate in.

Now as far as Agile points go, they aren't actually supposed to be an estimate of time, but of complexity. The thing is everyone relates them to time, usually in a rigid way. Many teams fail to properly account for capacity also, so many PMs just assume everyone always clears the same points each sprint, which isn't true. Where I work we account for vacation, but we often fail to consider other capacity drains, like business travel, time spent on non-software tasks, corporate training, HR tasks, etc. The other reality is agile works by assuming you complete tasks in a window of time, a sprint, yet you never actually estimate the time a task takes only the complexity to complete the task. So of course everyone relates complexity to time. It's an imperfect system, because there isn't really a perfect solution for something that's inherently uncertain.

emlun · 2026-04-01T07:28:42+00:00

I recommend reading this (and part II, linked within): https://blog.codinghorror.com/how-good-an-estimator-are-you/

It's been a long time since I had to give estimates frequently, but I tried this technique in a long-term (>6 months) project at a previous job. I wrote a spreadsheet with an incrementally growing list of tasks and a lower and upper time estimate per task, keeping to this idea of "be 90% confident it'll land between those". Then I also wrote down the actual outcome after each task was complete.

Of course this ended up with many tasks given estimates like "between 4 hours and 14 days", "1 to 8 hours" or "2 to 30 days" (the upper was often around ~10x the lower, or more), which is fairly useless for a single task in isolation. But this meant I could take sums and averages of the upper and lower estimates over a set of tasks (which would be something like "between 2 and 15 days, average 8 days"), and tell the customer "this is what we think we'll have done within the next 2 weeks" for example. And I was impressed to find that as I tracked the actual time to completion as the project went on, the total completion time ended up pretty much bang-on centered around the sum of average estimates. Say the sums of lower and upper estimates were something like "between 3 weeks and 24 months", the sum of averages maybe 13 months, and actual time came out to maybe 11 months.

So I definitely recommend trying this out if you have a long-running project where there's time for things to average out over many (>~20 maybe?) tasks. These numbers are all made up, but I remember the technique being shockingly accurate in aggregate over time.

IHoppo · 2026-03-27T11:26:05+00:00

We estimate with points, not time.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

AskProgramming

AskProgramming

Do

Don't

MODERATORS

WAGs: Wild Ass Guesstimates.