I think it's understandable why programmers dread doing estimates so much. But I believe there are multiple factors contributing to the current overall mess and the guilt should be shared among several areas -- and that includes us.
Estimates are often, if not always, mistaken as commitments or deadlines. But we don't do a great job on explaining that estimates are probabilistic by nature, there are risks involved, and leaving those risks entirely to developers may be comforting at the beginning, but harmful to the entire Organization in the long term.
Granted, that would be a huge cultural change, which surely is not going to happen overnight. Besides, political conditions are seldom in our favor. But I advocate that we should do the possible to dialogue.
I don't judge, and I recur to this solution as well, more often than I'd like to. But it doesn't only sounds bad.. it is bad indeed, for a number of reasons.
For instance, work usually expands to spend all the time available. Then, if you estimate a one-month task as four months, you will likely not win three months to spend on other tasks. You'll probably spend the whole four months on a one-month task instead.
Another issue: if you are competing for a project, over-estimates will translate in higher than necessary costs, and you may end up overpricing a project and missing the opportunity.
However, as I said, I don't judge and I also recur to that more often than not. On many Organizations, there aren't many other ways to deal with the matter. And that's why I say that the entire Organization looses: managers will have a good night of sleep after putting all the burden over your shoulders, but the losses are affecting every single stakeholder.
It's about time for them to start behaving a bit more responsibly.
Fair points, but I do not triple my estimations. Its more like added buffer for unforeseen risk. And I am careful to balance my team's well-being with the demands of business.
Yes, this is everyone's solution, all the way up the organizational hierarchy.
Software Engineer, it will take me 2 weeks. Engineering Manager it will take us 4 weeks. Product Manager it will take them 8 weeks. VP it will be done by the end of next quarter.
> But we don't do a great job on explaining that estimates are probabilistic by nature, there are risks involved
Ironically, I've recently been catching flak for "not being confident enough" when I give confidence intervals around my estimates indicating uncertainty.
When I am leading teams, I also ask for a certainty score along with the estimate, then track them together with daily updates. Like all human processes it is not infallible but it allows more reliable planning. I always wish I had a tool that would include this in the estimate process. Hansoft got close but nobody uses it!
Estimates are often, if not always, mistaken as commitments or deadlines. But we don't do a great job on explaining that estimates are probabilistic by nature, there are risks involved, and leaving those risks entirely to developers may be comforting at the beginning, but harmful to the entire Organization in the long term.
Granted, that would be a huge cultural change, which surely is not going to happen overnight. Besides, political conditions are seldom in our favor. But I advocate that we should do the possible to dialogue.