3 ms·

>> Managers like numbers, estimates, and asking for estimates with an idea written on a napkin. It's just how the real world works — a business has some monetar

>> Managers like numbers, estimates, and asking for estimates with an idea written on a napkin. It's just how the real world works — a business has some monetary goal, but before committing to it, it needs to understand how much it will cost. I think everyone squirms when asked to make a prediction with too little information. If you want to see a developer squirm. ask for an estimate for how long it will take to build a given product or feature. If you want to see a PO squirm, ask for an estimate (in $) of the expected cumulative revenues for the same product or feature.

kimburgess 4y ago
A lot of this stems from the accepted norm that an estimate is a single value. This loses a lot of information and when combined with other lossy estimates, this error compounds. Pair any estimate (time, cost, effort) with a confidence indicator. This will likely improve as more about the problem is known, but until then gives the ability to reason with appropriate certainty based on a set of inherently noisy priors. There’s a whole set of more formal systems such as PERT (https://en.m.wikipedia.org/wiki/Program_evaluation_and_review_technique https://en.m.wikipedia.org/wiki/Program_evaluation_and_revie...) which base off this principle. That doesn’t work for every project, but there’s often an over correction in ‘modern’ software teams where significant research, experience, and process that has been designed to avoid project chaos is completely ignored for the sake of being ‘lean’.
- valenterry 4y ago
  Exactly. As a minimum, it should be something like "90% chance it will be between 3 and 10 weeks, 50% chance it will be between 5 and 6 weeks". Optimally we have a probability distribution. Not to forget that over time the confidence will grow and estimates become more precise.
- kqr 4y ago
  A single value isn't the problem -- the lack of an indication of confidence is. If I say "there's a 90 % chance it's done before March 13." that's a useful and verifiable estimation, even though it's only one number.
  - brazzy 4y ago
    It's two numbers.
- osigurdson 4y ago
  >> A lot of this stems from the accepted norm that an estimate is a single value. If we want to estimate accurately, it is necessary to break work down into smaller pieces. However, we can only estimate the items that we can identify at the time of estimation (I.e., we know that we need to do A,B and C but discover that D,E and F are needed as well). The other factor is combinatorial explosion: we'll do A,B or C and this impacts what we do next. This graph can become enormous when attempting to construct up-front. I agree that having a probability distribution for each estimate is better than a single value. If you have two values, this is a uniform distribution. It is also possible to do a normal distribution, triangular, truncated normal, etc. However, it isn't clear to me that increased sophistication leads to better outcomes.
  - kimburgess 4y ago
    Completely agree. The overcorrection applies in both directions. The two value (estimate and confidence) is just a simple approach that is rather intuitive to interpret directly. As you note, diving into 3 point estimates gives to ability to extract beta distribution or other weightings that may or may not be suitable for the given domain. Complete top down planning for any work that involves discovery is useless, at best. That doesn't mean no planning is better. (Source: have experienced and been actively involved in both sides of that overcorrection.)
kqr 4y ago
Ironically, the question for the PO is the better question. Product/feature value usually spans a larger range of values than time to build it, so you don't need to estimate value as accurately for it to be a useful guide. It's also often easier to estimate because you wouldn't consider building it unless you have potential customers lined up. And then if the PO says "building this feature would earn us back 2 developer-months in the first year alone" it's usually very easy for a developer to judge if building it fits into that profit window or not. ---- Of course, nobody does this in practise because people suck at decision-making. The next time someone asks you "how much will it cost?" try asking them "how much is it worth our organisation? What are we willing to pay?" and it will be clear they have done zero analysis on cost/benefit. People don't know how to analyse -- or are uncomfortable with analysing -- these things so they are looking to be guided by their emotional response to information.

kimburgess 4y ago

A lot of this stems from the accepted norm that an estimate is a single value. This loses a lot of information and when combined with other lossy estimates, this error compounds. Pair any estimate (time, cost, effort) with a confidence indicator. This will likely improve as more about the problem is known, but until then gives the ability to reason with appropriate certainty based on a set of inherently noisy priors. There’s a whole set of more formal systems such as PERT (https://en.m.wikipedia.org/wiki/Program_evaluation_and_review_technique https://en.m.wikipedia.org/wiki/Program_evaluation_and_revie...) which base off this principle. That doesn’t work for every project, but there’s often an over correction in ‘modern’ software teams where significant research, experience, and process that has been designed to avoid project chaos is completely ignored for the sake of being ‘lean’.

valenterry 4y ago
Exactly. As a minimum, it should be something like "90% chance it will be between 3 and 10 weeks, 50% chance it will be between 5 and 6 weeks". Optimally we have a probability distribution. Not to forget that over time the confidence will grow and estimates become more precise.
kqr 4y ago
A single value isn't the problem -- the lack of an indication of confidence is. If I say "there's a 90 % chance it's done before March 13." that's a useful and verifiable estimation, even though it's only one number.
- brazzy 4y ago
  It's two numbers.
osigurdson 4y ago
>> A lot of this stems from the accepted norm that an estimate is a single value. If we want to estimate accurately, it is necessary to break work down into smaller pieces. However, we can only estimate the items that we can identify at the time of estimation (I.e., we know that we need to do A,B and C but discover that D,E and F are needed as well). The other factor is combinatorial explosion: we'll do A,B or C and this impacts what we do next. This graph can become enormous when attempting to construct up-front. I agree that having a probability distribution for each estimate is better than a single value. If you have two values, this is a uniform distribution. It is also possible to do a normal distribution, triangular, truncated normal, etc. However, it isn't clear to me that increased sophistication leads to better outcomes.
- kimburgess 4y ago
  Completely agree. The overcorrection applies in both directions. The two value (estimate and confidence) is just a simple approach that is rather intuitive to interpret directly. As you note, diving into 3 point estimates gives to ability to extract beta distribution or other weightings that may or may not be suitable for the given domain. Complete top down planning for any work that involves discovery is useless, at best. That doesn't mean no planning is better. (Source: have experienced and been actively involved in both sides of that overcorrection.)

kqr 4y ago

Ironically, the question for the PO is the better question. Product/feature value usually spans a larger range of values than time to build it, so you don't need to estimate value as accurately for it to be a useful guide. It's also often easier to estimate because you wouldn't consider building it unless you have potential customers lined up. And then if the PO says "building this feature would earn us back 2 developer-months in the first year alone" it's usually very easy for a developer to judge if building it fits into that profit window or not. ---- Of course, nobody does this in practise because people suck at decision-making. The next time someone asks you "how much will it cost?" try asking them "how much is it worth our organisation? What are we willing to pay?" and it will be clear they have done zero analysis on cost/benefit. People don't know how to analyse -- or are uncomfortable with analysing -- these things so they are looking to be guided by their emotional response to information.