5 ms·

I’m interested but not totally sure what you mean here. Do you have a source or name for this intervals/calibration stuff? I’ve always had issues when people a

I’m interested but not totally sure what you mean here. Do you have a source or name for this intervals/calibration stuff? I’ve always had issues when people are using hours instead of points. The one time we properly used points on a team it went really well.

kqr 4y ago
A good reference is Douglas Hubbard's How to Measure Anything. The idea is that most people can calibrate their sense of probability to be fairly accurate, by intentionally adjusting for some common biases. (In particular, if you prevent anchoring and availability bias, and actively engage system 2 and your loss aversion, you get a long way. There are specific techniques to do that in the book.) This is really easy to practise and test too, since all you need are a bunch of questions where the answer is known, but you are uncertain of it. Then you can guess a range in which you are 90 % certain the true answer lies, and after 10 such questions, you should be correct roughly 9 times. Points are a way to do this, but I prefer engineers who are calibrated. It's very powerful to ask someone for a calendar day when something will be done (or really just about any other question about anything), and be able to be reasonably confident in the span they respond with.
- greymalik 4y ago
  I’m a developer who’s been doing this for a loooong time and I can’t imagine being able to accurately guess with 90% confidence the calendar day I’ll have a particular task done. And the tasks I work on are different enough that a feedback loop about how much I misguessed would be useless for error-correcting future estimates. Maybe that works for factory-like tasks like how long it tasks to add a REST endpoint for a CRUD action?
  - kqr 4y ago
    No, it works for anything. The key that people misunderstand is that if the task is really uncertain, you're allowed to give a really wide range. In fact, you're supposed to -- that's the only way you can be correct 90 % of the time. As a concrete example, I recently estimated "somewhere between 1 week and 4 months" when asked about an semi-well specified feature because I felt there's a 5 % chance it's done in less than a week, but even under pessimistic assumptions, there's about a 5 % risk it takes longer than 4 months. When asked about a larger, unspecified projects a few years ago, I didn't hesitate to respond "between three months and 15 years". Sometimes that's the best you can do due to the uncertainties involved. It sounds useless, but it's really useful to have a quantitative measure of the uncertainty.

kqr 4y ago

A good reference is Douglas Hubbard's How to Measure Anything. The idea is that most people can calibrate their sense of probability to be fairly accurate, by intentionally adjusting for some common biases. (In particular, if you prevent anchoring and availability bias, and actively engage system 2 and your loss aversion, you get a long way. There are specific techniques to do that in the book.) This is really easy to practise and test too, since all you need are a bunch of questions where the answer is known, but you are uncertain of it. Then you can guess a range in which you are 90 % certain the true answer lies, and after 10 such questions, you should be correct roughly 9 times. Points are a way to do this, but I prefer engineers who are calibrated. It's very powerful to ask someone for a calendar day when something will be done (or really just about any other question about anything), and be able to be reasonably confident in the span they respond with.

greymalik 4y ago
I’m a developer who’s been doing this for a loooong time and I can’t imagine being able to accurately guess with 90% confidence the calendar day I’ll have a particular task done. And the tasks I work on are different enough that a feedback loop about how much I misguessed would be useless for error-correcting future estimates. Maybe that works for factory-like tasks like how long it tasks to add a REST endpoint for a CRUD action?
- kqr 4y ago
  No, it works for anything. The key that people misunderstand is that if the task is really uncertain, you're allowed to give a really wide range. In fact, you're supposed to -- that's the only way you can be correct 90 % of the time. As a concrete example, I recently estimated "somewhere between 1 week and 4 months" when asked about an semi-well specified feature because I felt there's a 5 % chance it's done in less than a week, but even under pessimistic assumptions, there's about a 5 % risk it takes longer than 4 months. When asked about a larger, unspecified projects a few years ago, I didn't hesitate to respond "between three months and 15 years". Sometimes that's the best you can do due to the uncertainties involved. It sounds useless, but it's really useful to have a quantitative measure of the uncertainty.