[newfoundglory]

Also, I think I figured out what I don't like about this answer - I don't want a dev to have outlined every task and designed the data structures to be used before they can figure out whether a feature will take closer to 6 or 18 months.

[afarrell]

And this is where I'm confused: where does a dev learn the skill of figuring out how long a feature will take before figuring out the user flows and data structures.

I've never worked on a project where I was estimating something at a scale of 6 months. But if you ask me whether something will take 1 week or 4 weeks, before I've broken the task down, my intuition is going to scream "I don't know the answer to that."

If I told you "Somewhere around 1 week to 2.5 months", would you accept that answer? Or would you think I was trolling you and we should have a conversation about my performance and place at the company?

If I instead told you "2 weeks", how would that be anything other than a lie?

[taeric]

I get the impression we are talking past each other. I certainly don't want every task outlined. Indeed, I don't necessarily want to know new data structures. I would expect an idea of what has to be modified. And if that isn't known, then I'd expect any estimate to be bad.

That said, my main point is that time estimates lead to bad negotiations. If someone says it will take six months and you need it in five, what is on the negotiation table? Just a month? This is how our industry often finds itself in crunch time, making up for time estimates gone awry.

Whereas if there is a list of things that can be negotiated, you can order the construction such that things are natural cuts.

[newfoundglory]

We do seem to be miscommunicating. If the estimate is six months and the deadline is five, then you ask what can be cut to make that work, and you talk in terms of reducing scope or quality of the work. And it doesn't work to just do things in order of importance - maybe if I need this feature this month it can be done, but if you give me three months then I can implement it in a more resilient/scalable/maintainable way that will also solve problems y and z. My point is probably that a lack of time estimates lead to bad planning.

[taeric]

My guess to where we are talking past each other is that I am asserting you can go from the work to the time. So, you should ask for that. You cannot go from the time to the work. (Again, both are assertions.) You seem to be saying you should just ask for the time, and only dig on the work if you aren't satisfied with the time.

If you are able to turn every estimation session into a series of back and forths where it is "how long?" followed by "why?" if you aren't satisfied, then I feel we are essentially agreeing. Whether you are asking for it or not, you want them to estimate the work required and to summarize it into a time.

And to be perfectly clear, going two people removed from the work, this is required. Similarly, getting 3 people removed from the work, the relevant question will not be "how long" but "how many dollars?"

Similarly, it would be nice to think everyone will eventually need the skill of estimating the value of a feature or product. Because, at the end of the day, that is what is most important.

However, I'm assuming anyone asking someone specifically for an estimate is one of their managers. And they should have more familiarity with what they are asking their colleagues to estimate. And I'm also asserting each of these skills is not trivial. And that they build on each other.