3 ms·
Why not then be honest about what kind of estimate is being made? How about saying "Can you give me ballpark estimates? On the order of days, weeks, months, yea
by godelski 2y ago
Why not then be honest about what kind of estimate is being made? How about saying "Can you give me ballpark estimates? On the order of days, weeks, months, years?" Then everyone knows it is a rough estimate and no one is forced to make impossible promises and trying to do the dumb "what I think multiply by 3" or whatever stuff goes on. Framed as ballpark or "rough" there's a clearer sense of shared ambiguity
- stavros 2y agoI feel like this is the crux of the issue. Dev estimates should be taken with large error bars, and I think the entire problem is caused by people who take them at face value, making developers not want to give estimates at all next time.
- prerok 2y agoWell, it helps if you have retrospectives, though I see them rarely done properly. What kind of works is tracking similar efforts (in the same code base) and measuring how long they take. While every task is different, there are usually a small number of different classes of tasks, and knowing how quickly these can be done helps in both estimating as well as defending the estimates.
- superfrank 2y agoPersonally, I almost always do. You're right one of the big problems is that people treat estimates as commitments and they're not that. They're called estimates because it's an estimate not a certainty. That isn't an issue with the estimates themselves though. It's a culture issue. Saying estimates are useless and I'm not going to do them because my company treats them as commitments is throwing the baby out with the bathwater, IMO.