[taeric]

I would advise not asking for timelines at all, actually. Instead, ask roughly what all they will have to do. How many tasks will it need. Do they need new datastructures, or is it modifying an existing one? Same for logical components. Modification, or addition? In either case, what are they modifying and what are they adding to?

If as the manager, you don't know enough about the codebase to get a sense of "last X development efforts on component Y took about Z weeks of effort", then it is your job to get to know the components better.

Note that doesn't mean building up the expertise to be able to do the changes yourself. Just that it should not be completely greek to you.

[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.

[newfoundglory]

I would probably ask for a timeline even if I felt like I could predict it myself, to help them learn how to do it. And as a manager, you can't always be an expert - sometimes you're the new guy, for instance.

[taeric]

But a timeline is of seriously limited value. You can't burn down on time. You can't combine time estimates. You can't work uncertainty into time estimates. The list could keep going.

I agree no estimation process is perfect. Nor do I think you should do comprehensive estimates on new work. However, the thing you want to know it's how much work there is. Not necessarily when you'd like to release a year from now.

Odds are high you have a deadline. So the incentive is high to keep the estimate below that line.

[newfoundglory]

Of course you can work uncertainty into time estimates.

That aside, the incentive is high to keep the amount of work planned below the amount of work that can be done before the deadline. It doesn't matter how many abstract units or concepts you use, that's what you want to know if you have a deadline.

[taeric]

Working uncertainty into time estimates still just gives you two sets of times to consider, with no way of knowing why you missed the low one and just if you will hit the high one. (Unless you do really wide bars on your estimates, in which case, the high bar is going to be worthless.)

That is, if you give me a high confidence and a low confidence estimate, how do I know why you missed it when the time passes? More, how "close" to making it were you? If you got half of the work you estimated done by that time, I'd know you were about halfway there. If the date just passed, all I know is that you didn't make it.

And I used "I" up there. But it is really even more personal. All you know is that you didn't make it. You literally don't have anything to learn there.

Contrasted with any work you do. Look back and quantify what you did. Not how long it took to do it.

[newfoundglory]

> If you got half of the work you estimated done by that time, I'd know you were about halfway there

And only 90% of the work remaining!

It sounds like you are imagining an estimate as a standalone number that isn't revisited or given more detail. If that's how you do it then of course you can't learn from it. It's supposed to be an ongoing process - if you said '3-6 months' when we started then after 2 months I'd expect a different answer. I'd also expect the initial estimate to be accompanied by an explanation that talks about the work to be done and which areas are causing uncertainty.

[afarrell]

> to help them learn how to do it

If you know of anything to read, watch, or work through to learn to estimate tasks, I would be extremely grateful if you could link or describe it here.

As it stands, I’ve only ever been able to estimate tasks if I’ve done similar ones a few times before. If asked about a new type of task or one with a new toolset, I would currently have to refuse an estimate more fine-grained than a week—-the stress and shame of lying to you would be too much otherwise

[taeric]

Consider how you would estimate anything else. Say you want to retile a kitchen. Would you expect someone to just say, I could do this in a weekend? Because, that is what shows typically seem to need?

Or would you feel more comfortable asking how much they will have to actually do? For example, they would have to disconnect the fridge and move it out of the way, disconnect the oven and move it out of the way, then buy enough tile and mortar for the space, which would be X boxes, and then clean and do the work.

Benefit of this way is when you come back, if none of those tasks has been done on day two, you know it isn't likely to get done on day two.

So, try and use the same approach for programming. Don't just say "it will take 2 weeks." Instead, say, it requires updating X component, modifying Y tests, incorporating Z new dependencies, etc...

As a team, you can try and portion size estimates on each of these. But don't spend too much time on that. Experience is the secret, not perfect estimates. (That is, the more things the team has done, the better they will estimate what they can do.)

[afarrell]

Right, my current approach, which works fairly well, is to spend some time writing out a couple approaches and splitting them it out into coherent delegatable tasks. This results in a 2-3 page doc that I can check with other engineers and business stakeholders to be sure it does what we really want it to. It also means we notice if an assumption we made is untrue and we need to re-think the scope or approach of the project.

I’m just worried that at some point, somebody will come along and ask for an estimate and I’ll say I cannot give one and that this means I am not really a professional.

[taeric]

Just be sure to do retrospectives on these documents and I'd wager that you are beyond any skill that I can lay claim to. Honestly, sounds like you are already beyond my skill levels.

Can't say if that helps strengthen your claim to professional, but that practice certainly sounds professional to me.

[newfoundglory]

There's nothing wrong with making imprecise estimates - the lack of precision is part of the information.

[afarrell]

So for time-based estimates, I've been given the advice to take what I think it will be and multiply by a factor of 4.

If it can be that far off (or more), what is the business value? And how do I know that the person I'm talking to will realize when I say "this will be done by the 20th" that I am thinking "I have no clue."?