How I estimate work • Hacker News Board

Re: How I estimate work

#231

Post by crazygringo » Sat, Jan 24, 2026, 11:42 PM UTC

Gooblebrai wrote: post #230

crazygringo wrote: post #215

Earlier quoted context omitted.

Remember, estimation is in points not days. It doesn't matter if it's 2 days work for a senior engineer or 4 days for junior devs, it's still the same number of points, e.g. 8 points. This is intentional. Skill is accounted for in the fact that a team of all senior devs might deliver 200 points a sprint, whereas if half the senior devs got replaced with junior devs the team might only deliver 100. This is intentional…

"estimation is in points, not days" doesn't tell me anything. Is not like tasks have an intrinsic attribute that everyone can agree on (e.g. the sky is blue) How are you estimating the points if not thinking about how hard the task is for you and how long is it going to take you? And then another matter is that points do not correlate to who later takes that work. If you are 5 seniors and 3 juniors and average on a t…

Here, you might want to read about it:

https://www.atlassian.com/agile/project-management/estimatio...

Points are not intrinstic or objective attributes, like the sky being blue. The scale is arbitrarily chosen by any given team, and relative to past work. But a common reference point is that 1 point is the "smallest" feature worth tracking (sometimes 1/2), and 20 points is usually the largest individual feature a team can deliver in a sprint. So it's common for teams to be delivering something between e.g. 50 and 200 points per sprint. Teams very quickly develop a "feel" for points.

> And then another matter is that points do not correlate to who later takes that work.

Yes, this is by design. Points represent complexity, not time. An experienced senior dev might tend to deliver 30 points per sprint, while a junior dev might usually deliver 10. If a team swaps out some junior devs for senior devs, you will expect the team to deliver more points per sprint.

Re: How I estimate work

#232

Post by stavros » Sat, Jan 24, 2026, 11:43 PM UTC

loloquwowndueo wrote: post #225

stavros wrote: post #205

Earlier quoted context omitted.

Because you have other benefits, so we'd really like to switch over to you, but we can't unless you support this dealbreaker feature that your competitor we're currently using has.

No, parent said they’d go talk to the competitor. They didn’t say they were already with them. Don’t change the scenario.

Because you have other benefits, so we'd really like to use you, but we can't unless you support this dealbreaker feature that your competitor has.

Re: How I estimate work

#233

Post by impute » Sat, Jan 24, 2026, 11:43 PM UTC

crazygringo wrote: post #227

turdprincess wrote: post #222

Earlier quoted context omitted.

Same - my new team doesn’t do any scrum or story points and it’s an amazing breath of fresh air - don’t miss those days just yelling random numbers at the zoom call for hours. The truth is on most teams one or two people who are closest to the task have enough context to estimate, and probably only after they spent some time starting or prototyping the task. Those people can give a reasonable estimate, in time not so…

Let me be clear -- nobody finds planning poker or story estimation fun . The same way nobody finds writing tests or documentation fun. So of course it'll be a breath of fresh air if it's not part of your job. But the fact remains that in most environments, it's extremely useful for medium-term planning and especially in surfacing high-risk features that can send people down the wrong path for a long time. And it's me…

How does it help with medium-term planning when it's just pointing tasks in one sprint?

Re: How I estimate work

#234

Post by Magmalgebra » Sat, Jan 24, 2026, 11:45 PM UTC

crazygringo wrote: post #215

spike021 wrote: post #199

Earlier quoted context omitted.

I've been on teams that tried various methods of estimating and the issue I always encounter is that everyone estimates work differently, but usually people will side with the person with the most context. For instance someone says a ticket is two days' work. For half the team that could be four days because people are new to the team or haven't touched that codebase, etc. But because the person who knows the ticket…

Remember, estimation is in points not days. It doesn't matter if it's 2 days work for a senior engineer or 4 days for junior devs, it's still the same number of points, e.g. 8 points. This is intentional. Skill is accounted for in the fact that a team of all senior devs might deliver 200 points a sprint, whereas if half the senior devs got replaced with junior devs the team might only deliver 100. This is intentional…

> is in points not days

I hear this often, but I've never met someone for whom points didn't eventually turn into a measurement of time - even using the exact process you're describing.

I think any process that's this hard to implement should be considered bad by default, barring some extraordinary proof of efficacy.

Re: How I estimate work

#235

Post by impute » Sat, Jan 24, 2026, 11:47 PM UTC

The only reliable way to estimate is to find another relatively similar project and compare it to that. You can say stuff like this new project is roughly similar in scope to Project X but maybe it's about 20% more complicated due to more scope so it will probably take about 20% longer than what Project X took.

The key is to keep data on how long past projects actually took (which not a lot of organizations do). But once you have that real data, you can understand all the unknown unknowns that came up and assume that similar things will come up on the new project.

Re: How I estimate work

#236

Post by crazygringo » Sat, Jan 24, 2026, 11:49 PM UTC

impute wrote: post #233

crazygringo wrote: post #227

Earlier quoted context omitted.

Let me be clear -- nobody finds planning poker or story estimation fun . The same way nobody finds writing tests or documentation fun. So of course it'll be a breath of fresh air if it's not part of your job. But the fact remains that in most environments, it's extremely useful for medium-term planning and especially in surfacing high-risk features that can send people down the wrong path for a long time. And it's me…

How does it help with medium-term planning when it's just pointing tasks in one sprint?

Because you often estimate something like three or four times as many tasks as actually get included in the sprint. You can't possibly know in advance which features will actually wind up in the sprint until you've considered all the possible candidates. You estimate, then the PM confers with stakeholders to prioritize what's actually most important and figure out the "puzzle" of which pieces add up to a coherent sprint, and then work starts.

To the developer, it seems like short-term sprint planning. But to the PM and stakeholders, it's very much medium-term planning because they're picking tasks for this sprint in light of what they also estimate the following couple sprints will look like (given current information, which is always going to change).

It's not as bad as it sounds, because when you're re-estimating something you already estimated in the past 2 planning pokers, it's usually pretty quick. You're just seeing if the previous estimate needs to be revised based on what the team has learned since. Most time is usually spent on newly proposed features, or features that have significantly changed or been split up.

Re: How I estimate work

#237

Post by impute » Sat, Jan 24, 2026, 11:50 PM UTC

pan69 wrote: post #165

wreath wrote: post #159

What often baffles me with engineers and especially engineering managers is that they don't derive the estimates from metrics of prior projects, especially for long running teams (as opposed to project teams). You don't need to estimate down to the minute, but you already know how many tickets/work items the completes at a given time interval with how many people in the team etc. This should give a rough estimate of…

How long does it take to do a crossword puzzle or play a game of chess?

You record the amount of time it takes people to do a crossword puzzle or play a game of chess. After a while you'll be able to make a distribution graph of how long it takes. Then you can give an accurate estimate along with a probability.

Re: How I estimate work

#238

Post by crazygringo » Sat, Jan 24, 2026, 11:55 PM UTC

Magmalgebra wrote: post #234

crazygringo wrote: post #215

Earlier quoted context omitted.

Remember, estimation is in points not days. It doesn't matter if it's 2 days work for a senior engineer or 4 days for junior devs, it's still the same number of points, e.g. 8 points. This is intentional. Skill is accounted for in the fact that a team of all senior devs might deliver 200 points a sprint, whereas if half the senior devs got replaced with junior devs the team might only deliver 100. This is intentional…

> is in points not days I hear this often, but I've never met someone for whom points didn't eventually turn into a measurement of time - even using the exact process you're describing. I think any process that's this hard to implement should be considered bad by default, barring some extraordinary proof of efficacy.

> I've never met someone for whom points didn't eventually turn into a measurement of time

The goal isn't to avoid time estimation completely, that would be crazy. People estimate how many points get delivered per sprint and sprints have fixed lengths of time. You can do the math, you're supposed to.

The point is that points avoid a false sense of precision: https://news.ycombinator.com/item?id=46748310

The process is quite easy to implement. And it does wind up with extraordinary efficacy gains on a lot of teams, that's the whole reason why it's so popular. But you do have to actually learn about it. Here:

https://www.atlassian.com/agile/project-management/estimatio...

Re: How I estimate work

#239

Post by cpeterso » Sat, Jan 24, 2026, 11:58 PM UTC

combatentropy wrote: post #133

This is clever advice, to first find out what estimate is tolerable to management and then adapt your design to fit. It's sort of like what the makers of Basecamp, in their book Getting Real, say in chapter 7, "Fix Time and Budget, Flex Scope" https://basecamp.com/gettingreal/02.4-fix-time-and-budget-fl... >. I wonder if it was a mistake to ever call it "engineering", because that leads people to think that software…

I like Basecamp’s framing of software development time as management’s “appetite” for a new feature, how much time they are willing to spend on a project, as opposed to an estimate. This helps time box development and control project scope.

https://basecamp.com/shapeup/4.5-appendix-06

Re: How I estimate work

#240

Post by Gooblebrai » Sun, Jan 25, 2026, 12:06 AM UTC

crazygringo wrote: post #231

Gooblebrai wrote: post #230

Earlier quoted context omitted.

"estimation is in points, not days" doesn't tell me anything. Is not like tasks have an intrinsic attribute that everyone can agree on (e.g. the sky is blue) How are you estimating the points if not thinking about how hard the task is for you and how long is it going to take you? And then another matter is that points do not correlate to who later takes that work. If you are 5 seniors and 3 juniors and average on a t…

Here, you might want to read about it: https://www.atlassian.com/agile/project-management/estimatio... Points are not intrinstic or objective attributes, like the sky being blue. The scale is arbitrarily chosen by any given team, and relative to past work. But a common reference point is that 1 point is the "smallest" feature worth tracking (sometimes 1/2), and 20 points is usually the largest individual feature a te…

So the PM must have the velocity of the team to be able to estimate timescales for the project, which is what they care about, and this velocity metric is only as good as the estimation of complexity points of a team?

> An experienced senior dev might tend to deliver 30 points per sprint

Seems a bit ironic that complexity doesn't measure time but then we are measuring how much complexity can someone deliver on average on a given time. Isn't complexity directly proportional to uncertainty factors, and therefore inversely proportional to confidence of time to completion?