3 ms·

Understanding the Monte Carlo Method

6 points by photon_lines 3y ago

SillyUsername 3y ago
I've recently been introduced to this as part of an agile dev process. The scrum master is using "the Monte Carlo method" to estimate how many tasks we'll get done in a sprint by generationally sampling 10,000 times, based on just 5(!) sprints so far. I personally think it's a load of BS until we start having sprints in at least in the high 20s because the equivalent bounding area will vary over time, based on staff availability, overtime, skill set required, complexity, and tech debt etc etc which can only be accurately estimated using many actual samples. With a high number of sprints the stats can effectively be collapsed into a bounded "box and whisker" average and confidence intervals anyway. This means there is no need for Monte Carlo in this field since it too only approximates using probability. The non technical scrum master is unable to explain to me how this works as it's black magic to them and all they do is fill in fields in a Jira plugin, and doesn't understand it at all (or my attempt to find how it's lack of data for the min/max - the bounding box - is somehow magically offset by 10,000 simulations) whilst he's trying to sing it's virtues to us. :shrug: I'd be interested to hear if anybody else can tell me why it would be any better if all it's doing is basing it's artificially generated "within area" values against the probability determined using only a small set of real samples (sprints).
- photon_lines 3y ago
  Using the monte carlo methodology for scrum estimation imo is a waste of time -- even time boxing in scrum itself is bullshit. It's impossible to accurately predict how much time it takes to get coding tasks done...just like the concept of adding new devs to a late project won't make it less late - trying to estimate how much each task takes won't make the project run smoother it'll only kill motivation and productivity but i suppose it's a regular part of modern everyday development so it is what it is :)

6 points by photon_lines 3y ago

I've recently been introduced to this as part of an agile dev process. The scrum master is using "the Monte Carlo method" to estimate how many tasks we'll get done in a sprint by generationally sampling 10,000 times, based on just 5(!) sprints so far. I personally think it's a load of BS until we start having sprints in at least in the high 20s because the equivalent bounding area will vary over time, based on staff availability, overtime, skill set required, complexity, and tech debt etc etc which can only be accurately estimated using many actual samples. With a high number of sprints the stats can effectively be collapsed into a bounded "box and whisker" average and confidence intervals anyway. This means there is no need for Monte Carlo in this field since it too only approximates using probability. The non technical scrum master is unable to explain to me how this works as it's black magic to them and all they do is fill in fields in a Jira plugin, and doesn't understand it at all (or my attempt to find how it's lack of data for the min/max - the bounding box - is somehow magically offset by 10,000 simulations) whilst he's trying to sing it's virtues to us. :shrug: I'd be interested to hear if anybody else can tell me why it would be any better if all it's doing is basing it's artificially generated "within area" values against the probability determined using only a small set of real samples (sprints).

photon_lines 3y ago
Using the monte carlo methodology for scrum estimation imo is a waste of time -- even time boxing in scrum itself is bullshit. It's impossible to accurately predict how much time it takes to get coding tasks done...just like the concept of adding new devs to a late project won't make it less late - trying to estimate how much each task takes won't make the project run smoother it'll only kill motivation and productivity but i suppose it's a regular part of modern everyday development so it is what it is :)