How I estimate work • Hacker News Board

Re: How I estimate work

#301

Post by cryptonector » Sun, Jan 25, 2026, 5:05 PM UTC

theptip wrote: post #67

> This is, of course, false. As every experienced software engineer knows, it is not possible to accurately estimate software projects. This is a cop-out. Just because you can’t do it, doesn’t mean it’s impossible :) There are many types of research and prototyping project that are not strongly estimable, even just to p50. But plenty can be estimated more accurately. If you are building a feature that’s similar to so…

> (IMO also it requires quite a lot of time investment, and that’s not always valuable, eg startups usually aren’t willing to implement the heavyweight process/rituals required to be accurate.)

Maybe, just maybe, it's because "the heavyweight process/rituals required to be accurate" might not be productive, and because being startups, and therefore small organizations, it's easier for everyone to know who's pulling their weight and who isn't, therefore "heavyweight process/rituals" add nothing and cost too much.

Mature organizations tend to "implement the heavyweight process/rituals required to be accurate" precisely because they are too large for everyone to know everyone, and so senior management loses touch with reality and starts feeling anxious about whether their R&D spend is yielding value. This is totally understandable, and we have to have empathy for executives, but there is tremendous danger in this approach. How many mature market leaders have had their lunch eaten by disruptive innovators (invariably startups)? And why? Maybe those "heavyweight" processes kill innovation! That urge to accurately measure what the org's devs are doing can be counterproductive.

All measures but one (so far) are gameable. So far only KTLO fraction, which one should couple with promoting a management culture that allows subjective value judgements to make it up and down the chain. Management of knowledge work essentially is a social problem, not a scientific one.

Re: How I estimate work

#302

Post by netghost » Sun, Jan 25, 2026, 5:42 PM UTC

crazygringo wrote: post #295

mitthrowaway2 wrote: post #275

Earlier quoted context omitted.

If you measure how long a hundred "3-day tasks" actually take, in practice you'll find a range that is about 2-12. The variance doesn't end up getting de-risked. And it doesn't mean the 3-day estimate was a bad guess either. The error bars just tend to be about that big.

If a story-sized task takes 4x more effort than expected, something really went wrong. If it's blocked and it gets delayed then fine, but you can work on other stories in the meantime. I'm not saying it never happens, but the whole reason for the planning poker process is to surface the things that might turn a 3 point story into a 13 point story, with everyone around the table trying to imagine what could go wrong.…

I think it really depends on how teams use their estimates. If you're locking in an estimate and have to stick with it for a week or a month, you're right, that's terrible.

If you don't strictly work on a Sprint schedule, then I think it's reasonable to have high variance estimates, then as soon as you learn more, you update the estimate.

I've seen lots of different teams do lots of different things. If they work for you and you're shipping with reliable results then that's excellent.

Re: How I estimate work

#303

Post by cryptonector » Sun, Jan 25, 2026, 7:12 PM UTC

theptip wrote: post #144

etamponi wrote: post #88

Earlier quoted context omitted.

> But plenty can be estimated more accurately. As a person that has never encountered a complex software project that can be accurately estimated, I am being a bit skeptical. The author did make examples of when estimation is possible: easy projects with a very short time horizons (less than an a couple of days, I'd say). I'd love to hear some examples of more complex software projects that can be estimated within a…

> easy projects with a very short time horizons (less than an a couple of days, I'd say). The example I quoted said hours, not days. But even taking your claim of days as estimable, I have seen much better. An example of weeks-long projects I regularly estimate accurately would be things like “in our Django monolith, add this new field/model, and update the state machine with these new transitions, and update the API…

> The example I quoted said hours, not days.

Yeah, that's a cop-out. All the easy things are easy! Well, yes, they are. It's the hard ones that -you know- are hard. That the easy things are easy is no real objection to TFA, it's just pedantry.

Re: How I estimate work

#304

Post by cryptonector » Sun, Jan 25, 2026, 7:13 PM UTC

theptip wrote: post #130

funrep wrote: post #84

Earlier quoted context omitted.

Did you read the article? They go on explain how you actually do it, in a very reasonable way.

Hi! “Did you read the article” is generally not in compliance with the HN community guidelines. Please don’t do this.

Pedantic commentary isn't terribly useful either.

Re: How I estimate work

#305

Post by cryptonector » Sun, Jan 25, 2026, 8:35 PM UTC

> Estimates are political tools for non-engineers in the organization. They help managers, VPs, directors, and C-staff decide on which projects get funded and which projects get cancelled.

> Estimates define the work, not the other way around

> The standard way of thinking about estimates is that you start with a proposed piece of software work, and you then go and figure out how long it will take. This is entirely backwards. Instead, teams will often start with the estimate, and then go and figure out what kind of software work they can do to meet it.

So true. But there are times when the thing to be built is known and an estimate is needed [for political reasons, as TFA explains], which is why sometimes it's the other way around.

Re: How I estimate work

#306

Post by numitus » Mon, Jan 26, 2026, 12:43 AM UTC

chrisfosterelli wrote: post #216

numitus wrote: post #172

Earlier quoted context omitted.

Incorrect analogy. Bridge construction is a clearly algorithmic process. All bridges resemble each other, and from an engineering perspective, designing one is not rocket science. Construction itself is a set of well-studied steps that can be easily calculated. If I were to write my operating system 100 times, I could give an estimate accurate to within 10%, but every task I’ve ever done in life is unique, and I have…

Software engineering isn't some magical, special branch of engineering in which no one piece of software resembles another, no well-studied steps can be replicated, and the design of which is equivalent to rocket science. If you're truly creating such unique and valuable software that it is to be compared to the world's engineering megaprojects in its challenge then perhaps it is beyond being beholden to a budget. Wh…

I’m not talking about difficulty; I’m talking about uniqueness—uniqueness for me personally. There are people who spend their whole lives designing bridges. I, on the other hand, have been writing software for 15 years, and almost every task I encounter is unlike the previous one. I’m not saying it’s difficult, but solving it requires gaining new experience that will be useless for future tasks. Sometimes, I have to do something similar to a previous task, but in 90 percent of cases, I first need to create documentation on how it currently works, figure out how to turn a task description consisting of a 15-word headline into a set of concrete actions, and then test it.

Re: How I estimate work

#307

Post by Magmalgebra » Mon, Jan 26, 2026, 1:50 AM UTC

crazygringo wrote: post #298

Magmalgebra wrote: post #276

Earlier quoted context omitted.

> The process is quite easy to implement Having implemented it myself, I agree it is easy to implement. My argument is that it is overly difficult to maintain . My experience is that incentives to corrupt the point system are too high for organizations to resist. Funnily enough - I work closely with a former director of engineering at Atlassian (the company whose guide you cite) and he is of the opinion that pointing…

I guess my experiences are quite the opposite. Maintaining the process couldn't be easier. I don't even know what it means to "corrupt" points...? Or for points to become "dishonest"? I'm genuinely baffled. I'm not aware of any citations, just like I'm not aware of any citations for most common development practices. It seems to be justified more in a practical sense -- as a team or business, you try it out, and see…

By "dishonest" I'm saying they become measurements of time, which is what we were trying to avoid.

Stepping back - my experience is that points are solving a problem good organizations don't have.

The practice I see work well is that a senior person comes up with a high level plan fror a project with confidence intervals on timeline and quality and has it sanity checked by peers. Stakeholders understand the timeline and scope to be an evolving conversation that we iterate on week-by-week. Our rough estimates are enough to see when the project is truly off-track and we can have a discussion about timelines and resourcing.

I just don't see what points do for me other than attempt to "measure velocity". In principle there's a metric that's useful for upper management, but the moment they treat it as a target engineers juice their numbers.

Re: How I estimate work

#308

Post by jimbokun » Mon, Jan 26, 2026, 2:35 AM UTC

HEmanZ wrote: post #138

Whenever this comes up I feel like I work on completely different kinds of software than most people here. (Giant, backend, distributed systems projects at FAANG) I’ve never worked on anything large in software where the time it will take can be reasonably deduced at the accuracy some people here seem to assume possible. The amount of unknown-unknowns is always way way too large and the process of discovery itself ex…

Estimating the time to transfer the needed data and one round of prototype is valuable information in that case.

Re: How I estimate work

#309

Post by mitthrowaway2 » Mon, Jan 26, 2026, 8:08 AM UTC

crazygringo wrote: post #295

mitthrowaway2 wrote: post #275

Earlier quoted context omitted.

If you measure how long a hundred "3-day tasks" actually take, in practice you'll find a range that is about 2-12. The variance doesn't end up getting de-risked. And it doesn't mean the 3-day estimate was a bad guess either. The error bars just tend to be about that big.

If a story-sized task takes 4x more effort than expected, something really went wrong. If it's blocked and it gets delayed then fine, but you can work on other stories in the meantime. I'm not saying it never happens, but the whole reason for the planning poker process is to surface the things that might turn a 3 point story into a 13 point story, with everyone around the table trying to imagine what could go wrong.…

Try systematically collecting some fine grained data comparing your team's initial time estimates against actual working time spent on each ticket. See what distribution you end up with.

Make sure you account for how often someone comes back from working on a 3-point story and says "actually, after getting started on this it turned out to be four 3-point tasks rather than one, so I'm creating new tickets." Or "my first crack at solving this didn't work out, so I'm going to try another approach."

Re: How I estimate work

#310

Post by n4r9 » Mon, Jan 26, 2026, 8:56 AM UTC

crazygringo wrote: post #291

n4r9 wrote: post #277

Earlier quoted context omitted.

Can't you do that by just limiting the precision? You can only vote 1, 2, 3, 5 or 8 days. Not sure what "points" are adding. As far as I can tell, it's an attempt to account for estimation difficulties by introducing a "velocity" concept. But I think it makes things more complex without actually solving the issue.

Let me repeat myself: > and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc. > But again, for whatever psychological reason, people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days. The points imply more of an estimated goal than a deadline guarantee, which helps keep…

> and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc.

> people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days

Okay I think I'm with you. In my team, the PM pre-calculates the number of available days in the sprint per developer before taking any estimates, factoring in planned holidays and estimates of sickness and meeting time, and adjusting for seniority. I guess points are kind of a crude way of doing the same thing.