4 ms·

They mentally convert the points to some "X days" and then beat you in the head with it. That's actually why I really dislike Fibonacci estimation. If we j

They mentally convert the points to some "X days" and then beat you in the head with it. That's actually why I really dislike Fibonacci estimation. If we just estimated days or hours, then I could say, "Okay, this is going to take me until Wednesday," my manager would reply with, "Wednesday? It's going to take that long?" and then we could have a discussion about why it's going to take so long. Or, worst case, manager says, "quanticle, I really need this to be done by Tuesday," and I know I'm going to be staying late until it's done. But with Fibonacci numbers, it's like, I estimate a 3, manager nods and agrees that this task is a 3, and then it turns out that when I said 3, I meant that it'd take until Wednesday, but manager thought that a 3 point task would be done by Tuesday, and now manager is mad at me, and I don't know why. The old way sucked, but at least it sucked in an up-front and transparent way.

LanceH 4y ago
When you vote in Fibonacci and it's really simple, do you vote a 1, or 1?
- majikandy 4y ago
  I prefer 1 or 0, do or do not. The rest of the sequence is meaningless. If you are truly in a position where two different features will bring the company £5mil of revenue and one is a 3 and one is a 13, just do both, no need to prioritise the 3.
and0 4y ago
For me the most absurd conversation around Fibonacci estimation is the burndown (etc) charts and group estimates.. you can't add non-linear values and expect the sum to mean anything! I've had managers fight over how the upcoming sprint is doable because it has around as many total points as the last, ignoring that they've defined the individual five-pointers as being significantly more effort than five individual one-pointers. And they either fail to grasp the issue or deflect when it's pointed out. Agile is a cudgel.
- quanticle 4y ago
  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.
maerF0x0 4y ago
> and I know I'm going to be staying late until it's done. I cant tell you how many times I spent long days, 16 hours at a time, sometimes over the weekend etc. Only to have the manager stroll in monday talking about how great their weekend was, and barely acknowledge the item was completed. And then I find out the customer that "needed this so bad" didn't touch it for the next month. Or were never told it was deployed etc. So many deadlines are fake that it's hard to trust any deadline.
- quanticle 4y ago
  Fake or not, at least you were told what the deadline was. The agile approach to this dysfunction is for you to be pulled aside at some point and told, "You're not delivering enough points," with the manager remaining extremely vague about how many points is "enough".
- seadan83 4y ago
  I think you illustrated the point of the deadline well. How else were they going to get you to work 16 hours days? No way to make someone eat the cost of estimation error by pretending there is no error and making job performance and team esteem dependent on "not failing the sprint".
lmm 4y ago
> manager says, "quanticle, I really need this to be done by Tuesday," and I know I'm going to be staying late until it's done. At some point you have to grow a pair and create the workplace you want. (Or, y'know, unionize). Tell them to fuck off. > But with Fibonacci numbers, it's like, I estimate a 3, manager nods and agrees that this task is a 3, and then it turns out that when I said 3, I meant that it'd take until Wednesday, but manager thought that a 3 point task would be done by Tuesday, and now manager is mad at me They're explicitly not allowed to do that. If they're claiming to follow Scrum then that's a promise not to do that. At some point all I can suggest is "don't work for a liar". Of course that may be easier said than done. > The old way sucked, but at least it sucked in an up-front and transparent way. I agree that pretending to follow good practices while following bad practices can be worse than honestly folowing bad practices. But that doesn't mean that good practices are worse than bad practices!
- quanticle 4y ago
  At some point all I can suggest is "don't work for a liar". Of course that may be easier said than done. The point of my anecdote was to illustrate how Agile makes it easier to lie, and makes it difficult for honest people to call out liars. If a manager tells me that the deadline is Wednesday, and the deadline passes without anything bad happening, then he or she looks bad. If a manger estimates a "3", and I estimate a "3", and then it turns out that our definitions of what a "3" is differ, then I look bad, regardless of whether the work was, in reality a "3", a "5", or a "3.1415926". But that doesn't mean that good practices are worse than bad practices! The worst practice of all is a bad practice that masquerades as a good practice. I'd much rather that people be honest and up-front about the deadline (even if it is BS) than try to hide behind some overly complicated poker-game kabuki.
  - lmm 4y ago
    > The point of my anecdote was to illustrate how Agile makes it easier to lie, and makes it difficult for honest people to call out liars. If a manager tells me that the deadline is Wednesday, and the deadline passes without anything bad happening, then he or she looks bad. If a manger estimates a "3", and I estimate a "3", and then it turns out that our definitions of what a "3" is differ, then I look bad. If your manager says they're following agile/scrum and says you took too long on that "3", they're lying and you should call them out; you don't look bad, they do. > I'd much rather that people be honest and up-front about the deadline (even if it is BS) than try to hide behind some overly complicated poker-game kabuki. If you've got a real deadline then be honest about it. But most everyday tasks don't need a deadline; agile isn't about pretending the deadline isn't a deadline, it's about actually not having a deadline.
OJFord 4y ago
Also, when we say we have an appetite/capacity for X points in the (Y-week) sprint, that would actually make sense! Drives me mad calling the points 'complexity', explicitly not time, and then talking about how much complexity fits in the allotted time period...

LanceH 4y ago

When you vote in Fibonacci and it's really simple, do you vote a 1, or 1?

majikandy 4y ago
I prefer 1 or 0, do or do not. The rest of the sequence is meaningless. If you are truly in a position where two different features will bring the company £5mil of revenue and one is a 3 and one is a 13, just do both, no need to prioritise the 3.

and0 4y ago

For me the most absurd conversation around Fibonacci estimation is the burndown (etc) charts and group estimates.. you can't add non-linear values and expect the sum to mean anything! I've had managers fight over how the upcoming sprint is doable because it has around as many total points as the last, ignoring that they've defined the individual five-pointers as being significantly more effort than five individual one-pointers. And they either fail to grasp the issue or deflect when it's pointed out. Agile is a cudgel.

quanticle 4y ago
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.

maerF0x0 4y ago

> and I know I'm going to be staying late until it's done. I cant tell you how many times I spent long days, 16 hours at a time, sometimes over the weekend etc. Only to have the manager stroll in monday talking about how great their weekend was, and barely acknowledge the item was completed. And then I find out the customer that "needed this so bad" didn't touch it for the next month. Or were never told it was deployed etc. So many deadlines are fake that it's hard to trust any deadline.

quanticle 4y ago
Fake or not, at least you were told what the deadline was. The agile approach to this dysfunction is for you to be pulled aside at some point and told, "You're not delivering enough points," with the manager remaining extremely vague about how many points is "enough".
seadan83 4y ago
I think you illustrated the point of the deadline well. How else were they going to get you to work 16 hours days? No way to make someone eat the cost of estimation error by pretending there is no error and making job performance and team esteem dependent on "not failing the sprint".

lmm 4y ago

> manager says, "quanticle, I really need this to be done by Tuesday," and I know I'm going to be staying late until it's done. At some point you have to grow a pair and create the workplace you want. (Or, y'know, unionize). Tell them to fuck off. > But with Fibonacci numbers, it's like, I estimate a 3, manager nods and agrees that this task is a 3, and then it turns out that when I said 3, I meant that it'd take until Wednesday, but manager thought that a 3 point task would be done by Tuesday, and now manager is mad at me They're explicitly not allowed to do that. If they're claiming to follow Scrum then that's a promise not to do that. At some point all I can suggest is "don't work for a liar". Of course that may be easier said than done. > The old way sucked, but at least it sucked in an up-front and transparent way. I agree that pretending to follow good practices while following bad practices can be worse than honestly folowing bad practices. But that doesn't mean that good practices are worse than bad practices!

quanticle 4y ago
At some point all I can suggest is "don't work for a liar". Of course that may be easier said than done. The point of my anecdote was to illustrate how Agile makes it easier to lie, and makes it difficult for honest people to call out liars. If a manager tells me that the deadline is Wednesday, and the deadline passes without anything bad happening, then he or she looks bad. If a manger estimates a "3", and I estimate a "3", and then it turns out that our definitions of what a "3" is differ, then I look bad, regardless of whether the work was, in reality a "3", a "5", or a "3.1415926". But that doesn't mean that good practices are worse than bad practices! The worst practice of all is a bad practice that masquerades as a good practice. I'd much rather that people be honest and up-front about the deadline (even if it is BS) than try to hide behind some overly complicated poker-game kabuki.
- lmm 4y ago
  > The point of my anecdote was to illustrate how Agile makes it easier to lie, and makes it difficult for honest people to call out liars. If a manager tells me that the deadline is Wednesday, and the deadline passes without anything bad happening, then he or she looks bad. If a manger estimates a "3", and I estimate a "3", and then it turns out that our definitions of what a "3" is differ, then I look bad. If your manager says they're following agile/scrum and says you took too long on that "3", they're lying and you should call them out; you don't look bad, they do. > I'd much rather that people be honest and up-front about the deadline (even if it is BS) than try to hide behind some overly complicated poker-game kabuki. If you've got a real deadline then be honest about it. But most everyday tasks don't need a deadline; agile isn't about pretending the deadline isn't a deadline, it's about actually not having a deadline.

OJFord 4y ago

Also, when we say we have an appetite/capacity for X points in the (Y-week) sprint, that would actually make sense! Drives me mad calling the points 'complexity', explicitly not time, and then talking about how much complexity fits in the allotted time period...