That brings to mind the other issue I have with fibonacci estimation: it makes improvement impossible.
In any high-performance organization, there is periodic self-reflection and self-improvement. Professional sports teams will, for example, sit down and "watch the tape", reviewing video of their most recent game(s) to see what they've been doing well and what they've been doing poorly, drilling down into specific areas where they need further practice.
Agile pays lip-service to this practice with its end-of-sprint retrospectives, but I've never seen an agile team do anything approaching a ticket-by-ticket breakdown, going over why the estimate was wrong, and what could be done to improve estimation in the future. One of the reasons that teams don't do this is because Fibonacci estimation makes it impossible to do this sort of thing. If I estimate that a task was a "3", and it took me two days to finish, did I estimate correctly? How could I have estimated better? These questions don't even make sense without a common baseline for what these numbers mean.
That's what I find most frustrating about Agile, as it is practiced. It's not the fact that the estimates are wrong. It's the fact that the estimates are so meaningless that they're not-even-wrong, in a way that makes it impossible to find and adjust for biases.
In any high-performance organization, there is periodic self-reflection and self-improvement. Professional sports teams will, for example, sit down and "watch the tape", reviewing video of their most recent game(s) to see what they've been doing well and what they've been doing poorly, drilling down into specific areas where they need further practice.
Agile pays lip-service to this practice with its end-of-sprint retrospectives, but I've never seen an agile team do anything approaching a ticket-by-ticket breakdown, going over why the estimate was wrong, and what could be done to improve estimation in the future. One of the reasons that teams don't do this is because Fibonacci estimation makes it impossible to do this sort of thing. If I estimate that a task was a "3", and it took me two days to finish, did I estimate correctly? How could I have estimated better? These questions don't even make sense without a common baseline for what these numbers mean.
That's what I find most frustrating about Agile, as it is practiced. It's not the fact that the estimates are wrong. It's the fact that the estimates are so meaningless that they're not-even-wrong, in a way that makes it impossible to find and adjust for biases.