The best estimate we can provide for non-trivial development is always an educated guess made in good faith. Here's a partial explanation of why we...
For further actions, you may consider blocking this person and/or reporting abuse
Love it!
Mike Cohn's excellent book Succeeding with Agile, chapter 15 Planning has a section called Separate Estimating from Committing.
I think it is important to emphasize that an estimate is not a commitment. I would only be willing to give an estimate as an iron-clad commitment if I am allowed to give the estimate after the work is done. ;-)
For those teams that use story points and calculate velocity as story points per sprint, the theory is that velocity is a better way to estimate how long it will take to get how much work done (with some range and confidence); or vice versa, given a target date, how much work is expected to be done at a minimum, and how much work may possibly be done as a maximum, and what work will not be done.
Using historical data ("yesterday's weather") as a predictor is a good thing, in conjunction with short iterations and an empirical approach. Works much better than wishful thinking, gut feel, and hand-waving that I've seen with Gantt charts laid out at the start of a project by a project manager who was unable to account for every sickness, mistake, requirement change, or surprise work discovered during development. (Gantt charts that are written in pencil, fluid, continuously adjusted & updated, as a map-and-a-plan to get from here-to-there are okay. Gantt charts that carved in stone, are immutable, drives the goals and milestones, and slippages are blamed on others are not good.)
Thanks Scott!
I have regular conversations with people who ask for estimates, and quite often we find that there isn't much point unless there are choices to be made, things like do we/don't we, what else could we do?
Without choices, that are taken based on estimated time/cost, they really don't add much value.