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.
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.
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.
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.
> 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.
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
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.)
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.
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.
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."?
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.