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.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.)