> 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

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