Ask HN: How do you do estimates in 2021?

> Pick a low number to win the bid, blow the timeline/estimate, require more money to do anything at all.

Except that there are penalty mechanisms in place to prevent this from happening.

So your company was slow to deliver the product and needs more time? You better be prepared to work for your own resources, otherwise the escrow won't get released, as per the contract.

Or perhaps you cannot finish it at all? Get ready to either not receive a large portion of the money at all, or to be sued outright. For an example, see here: https://www.consulting.us/news/2197/accenture-sued-for-32-mi...

Disclaimer: i have nothing to do with Accenture or consulting in the US, though consulting, government contracts etc. all share certain similarities and bureaucratic processes in most countries that don't always align with the realities of actually developing software.

If you can, steer clear of all of that and instead work for a technology oriented company that develops a product that they also sell themselves. One, in which the developers are viewed as a profit center, instead of a cog in a ROI generation machine. Ideally, an engineering led company.

I don't do estimates. I put anchor dates months in advance, and track progress with the different teams through weeklies.

Project planning that breaks tasks down into granular dates just begs everyone to disrespect it once dates inevitably start slipping. Don't do that, just keep an eye on the important dates and give your teams the headroom to work.

In your case I'd set strategic goals for the year to align with the business, then plan anchor dates (such as key releases) on a month or two month level for the entire year, then work back dependency and tech roadmap from there.

Also keep some capacity in reserve. Plan your yearly goals conservatively but your anchor dates a bit more aggressively.

Then once the plan is in place, keep track through weeklies or something unobtrusive like that.

I agree. Actually this is just fake estimation, it's really this: being pressured into commiting to doing 3 times as much as you can do.

If the goal was a genuine estimate, the next year you would surely multiply your estimate by 3 and get closer, maybe overestimate that year

Using the estimation session to highlight missing / poorly specified requirements, or discover external dependencies can be a worthwhile exercise IMO, the actual numbers are fairly worthless.

For what it's worth, most places I've worked at pretend to use points, but at some point directly translate the points to days anyway.

Also in the last 10 years (which is roughly when I started to encounter agile in the workplace) I've not worked anywhere that didn't have its release schedule set by marketing or product or legal. Yet everywhere paid lip service to developer estimation.

Also, also, I've never encountered an Epic which got over-estimated, which kind of gives the game away doesn't it?

3x fits pretty much every engineering project I've worked on.