In the 16 years since I started in this industry, I've only worked in one place where estimation was even slightly accurate, and that was in 2006 at a place that did Extreme Programming and used a vague notion of story points (mostly inaccurate) and "ideal hours" for tasks which tended to be more meaningful but still not very useful.
Since then, I've worked in a few teams where management thought Fibonacci points estimation was a good idea. It never was, as far as I can tell. Planning poker invariably led to long debates that were unproductive and led to tension and frustration:
Lead: Ruttiger, everyone else said 5 points and you said 8. Want to explain why, or change your estimate to agree with the others?
Ruttiger: Well, I don't really know how to do this thing, and...
Lead: We don't factor that in the estimates.
Ruttiger: Why not? Isn't that a very important factor?
T-Shirt sizing sounds more promising but I've seen it used to map each size onto a time period (say 2 days for small, 5 for medium, 10 for large) which then feeds into a Gannt chart of predicted work sequencing and targets, which is dangerous, but if your management thinks in terms of "failure to meet targets" instead of "targets were incorrect", then you have problems either way.
On teams where we did detailed estimation and sprint planning, I've tried to gently point out that I've almost never seen any team actually finish a sprint because they always feel pressured to load it with more and more tasks, making bigger commitments to avoid being seen as bad team players. This isn't their fault, but rather a natural consequence of detailed estimation and sprint planning. However I've rarely made the argument successfully and at least once suffered for trying to make the case. Sometimes there is an almost religious commitment to a particular model of "Agile" which is definitely not agile.
Speaking of the pressure to commit and deliver based on uninformed predictions, I've also spoken to good devs who got bad performance reviews from their manager because it took them 4 days to do a task that had only been estimated 1 point by the team. Imagine how unfair that would feel, and the negative effects it would have on morale and trust.
There was only one benefit I've seen from estimation, and that's simply thinking and talking about tasks with the team. Someone would often raise a really important point that saves us wasted effort later.
If teams would just spend a few minutes discussing upcoming work, looking for gotchas or proposing an approach to difficult problems, then THROW AWAY any estimates, they might get more value and less pain from the whole thing. Also, throw away your sprint board and try Kanban for the same reason. Sprints don't really work and they just lead to a regular feeling that the team has failed to meet targets.
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.
In the 16 years since I started in this industry, I've only worked in one place where estimation was even slightly accurate, and that was in 2006 at a place that did Extreme Programming and used a vague notion of story points (mostly inaccurate) and "ideal hours" for tasks which tended to be more meaningful but still not very useful.
Since then, I've worked in a few teams where management thought Fibonacci points estimation was a good idea. It never was, as far as I can tell. Planning poker invariably led to long debates that were unproductive and led to tension and frustration:
T-Shirt sizing sounds more promising but I've seen it used to map each size onto a time period (say 2 days for small, 5 for medium, 10 for large) which then feeds into a Gannt chart of predicted work sequencing and targets, which is dangerous, but if your management thinks in terms of "failure to meet targets" instead of "targets were incorrect", then you have problems either way.
On teams where we did detailed estimation and sprint planning, I've tried to gently point out that I've almost never seen any team actually finish a sprint because they always feel pressured to load it with more and more tasks, making bigger commitments to avoid being seen as bad team players. This isn't their fault, but rather a natural consequence of detailed estimation and sprint planning. However I've rarely made the argument successfully and at least once suffered for trying to make the case. Sometimes there is an almost religious commitment to a particular model of "Agile" which is definitely not agile.
Speaking of the pressure to commit and deliver based on uninformed predictions, I've also spoken to good devs who got bad performance reviews from their manager because it took them 4 days to do a task that had only been estimated 1 point by the team. Imagine how unfair that would feel, and the negative effects it would have on morale and trust.
There was only one benefit I've seen from estimation, and that's simply thinking and talking about tasks with the team. Someone would often raise a really important point that saves us wasted effort later.
If teams would just spend a few minutes discussing upcoming work, looking for gotchas or proposing an approach to difficult problems, then THROW AWAY any estimates, they might get more value and less pain from the whole thing. Also, throw away your sprint board and try Kanban for the same reason. Sprints don't really work and they just lead to a regular feeling that the team has failed to meet targets.