Ask HN: Should developers provide time estimates?

Is your company requiring hour or even minute accuracy of the estimate?

In my whole professional life, I have not been put in such situation, even when working as consultant where we charge by the hour -- we simply estimate by week or day then multiply.

The art part of estimation is setting expectations, or more precisely, adding and justifying buffer time, and form an acceptable narrative when the schedule deviate from plan.

There are different kinds of estimates used for different purposes. When making an estimate, know what it's for and if it has any value at all or can be omitted.

Very high-level estimates can be used to decide whether to do one project or another. Here we're both guessing time/cost as well as expected value. If unclear do some work to make better guesses of time/cost or expected value.

Estimates can also be used go co-ordinate with other teams if there are scheduling dependencies. Communicate early and often. Do some work to validate estimates. Complete tasks in a way that makes other estimates more accurate. e.g. deploy the smallest feature to prod with all steps completed rather than 100% of scope 10% done. If it's an external team, make your best guess, leave some room and aim to be early because you won't be.

Estimates to fill plan/fill work weeks are mostly a waste of time. Instead identify what's important, break them down into small parts with the immediately sequenced parts in higher resolution and do as many as you can in a natural order.

You can still schedule tasks expected to be completed in a cycle but it's a direct assessment as in "I can do items 1 & 4 in the next two weeks" not an abstract each item got a team-agreed T-shirt size and you've been selected to do these ones that add up to 10 days.

There is a secondary discussion if developers should be accountable for sticking to estimates, and my opinion is that they shouldn't - developers should be accountable for the quality and maintainability of the produced code, documentation and tests, not timelines - that's the job of the PM. A good PM will be able to observe that on average the unit of estimation takes 20% longer or shorter and adjust the project timelines accordingly. Also, if someone is worried about developer productivity, it can always evaluate it in relative terms, i.e. how many tasks generated with the above method does one developer execute vs another developer in the same unit of time.

There is a fair chance I maybe an idiot but I've rarely worked on a problem where I could:

"thoroughly understand the requirements and truly define the solution approach, leaving the time estimate to be just a matter of counting the generated tasks"

The problems I've been paid to solve are problems that haven't been solved yet or at least I have never solved them before so I would have difficulty making a estimate.

(This isn't meant as a criticism. It's just my experience.)