4 ms·

The trouble with estimates is that they're always wrong, and we're left to deal with the degree in which they're wrong. The problem with that is that we have n

The trouble with estimates is that they're always wrong, and we're left to deal with the degree in which they're wrong. The problem with that is that we have no insight on how much they'll be wrong and our reputations as developers get hung out to dry on those. I think its better to work with what you can control. You can size stories (S, M, L, XL) to the point of consensus with everyone in the room; so work with that. The next best thing you can do is to agree to work diligently with your team to implement those stories, without waste, towards a stakeholder and team agreed _definition of done_.

jon-wood 10y ago
These days I sit somewhere in the middle, I don't give precise estimates because they'll inevitably be wrong, but I am willing to use a kind of log scale when estimating tasks with real time. Estimates come in the form of n hours, n days, n weeks, or n months, and a heavy caveat that the less granular the estimate the less accurate I expect it to be. I'll also never commit to working on any task with an estimate over a day or two, weeks and months are solely for long term planning and deciding which of several large projects should be taken on first.
- seanwilson 10y ago
  Sounds sensible to me. For longer tasks, I also think it's useful to say (where practical) "I'm really not sure because there are too many unknowns but if you let me work on it for X hours first I can provide a more accurate estimate then". I think the important points are to always caveat estimates, build risks + unknowns into the estimates, update estimates as the situation evolves and never allow yourself to commit to an estimate with too many unknowns.
seanwilson 10y ago
> The trouble with estimates is that they're always wrong, and we're left to deal with the degree in which they're wrong. I would only ever say an estimate was wrong if it was widely out and you could have reasonably been a lot more accurate with a small amount of effort. Once people accept that some estimates will turn out to be too high and too some too low but they should mostly balance out instead of treating them all as very accurate it should be less of an issue. > The problem with that is that we have no insight on how much they'll be wrong and our reputations as developers get hung out to dry on those. That's a team problem with how estimates are treated that has to be fixed though. Estimates are estimates and not reading the future. If developers are treated like that for estimates the same problem will just manifest with whatever other system you come up with. > I think its better to work with what you can control. You can size stories (S, M, L, XL) to the point of consensus with everyone in the room; so work with that. What would you do for a fixed price project then where the client wants an agreed figure to pay for a delivered product (e.g. a few months of work)? If you're too high they won't accept the contract and if you're too low you'll lose money. You cannot avoid estimates here.

jon-wood 10y ago

These days I sit somewhere in the middle, I don't give precise estimates because they'll inevitably be wrong, but I am willing to use a kind of log scale when estimating tasks with real time. Estimates come in the form of n hours, n days, n weeks, or n months, and a heavy caveat that the less granular the estimate the less accurate I expect it to be. I'll also never commit to working on any task with an estimate over a day or two, weeks and months are solely for long term planning and deciding which of several large projects should be taken on first.

seanwilson 10y ago
Sounds sensible to me. For longer tasks, I also think it's useful to say (where practical) "I'm really not sure because there are too many unknowns but if you let me work on it for X hours first I can provide a more accurate estimate then". I think the important points are to always caveat estimates, build risks + unknowns into the estimates, update estimates as the situation evolves and never allow yourself to commit to an estimate with too many unknowns.

seanwilson 10y ago

> The trouble with estimates is that they're always wrong, and we're left to deal with the degree in which they're wrong. I would only ever say an estimate was wrong if it was widely out and you could have reasonably been a lot more accurate with a small amount of effort. Once people accept that some estimates will turn out to be too high and too some too low but they should mostly balance out instead of treating them all as very accurate it should be less of an issue. > The problem with that is that we have no insight on how much they'll be wrong and our reputations as developers get hung out to dry on those. That's a team problem with how estimates are treated that has to be fixed though. Estimates are estimates and not reading the future. If developers are treated like that for estimates the same problem will just manifest with whatever other system you come up with. > I think its better to work with what you can control. You can size stories (S, M, L, XL) to the point of consensus with everyone in the room; so work with that. What would you do for a fixed price project then where the client wants an agreed figure to pay for a delivered product (e.g. a few months of work)? If you're too high they won't accept the contract and if you're too low you'll lose money. You cannot avoid estimates here.