4 ms·

This sounds like it's written by someone who's only been in teams that do point estimations. Those are, almost by definition, 100 % incorrect because even small

by kqr 4y ago

This sounds like it's written by someone who's only been in teams that do point estimations. Those are, almost by definition, 100 % incorrect because even small variations mean you're not done exactly when you said you'd be done. If you estimate in properly calibrated 90 % intervals, you'll be correct 90 % of the time, and this is something you can verify continually.

code_runner 4y ago
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.
marcinzm 4y ago
My company right now does OKRs with priority levels for each task. If you make it a P0 then you're saying it will get done this quarter baring really unexpected circumstances (ie: shit happens, we understand). P1 may not get done. P2 is even less likely to get done. This creates a natural distribution by holding the date constant and varying the work done by that date. Personally I find this more reliable and easier to communicate than holding the work constant and varying the date of each item.
- kqr 4y ago
  To be honest, I also like that approach better, because in my experience the budget tends to be relatively fixed, but the work amount is often fairly flexible.

by kqr 4y ago

code_runner 4y ago

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.

marcinzm 4y ago

My company right now does OKRs with priority levels for each task. If you make it a P0 then you're saying it will get done this quarter baring really unexpected circumstances (ie: shit happens, we understand). P1 may not get done. P2 is even less likely to get done. This creates a natural distribution by holding the date constant and varying the work done by that date. Personally I find this more reliable and easier to communicate than holding the work constant and varying the date of each item.

kqr 4y ago
To be honest, I also like that approach better, because in my experience the budget tends to be relatively fixed, but the work amount is often fairly flexible.