5 ms·

I worked on something similar[1] and was totally hamstrung by front-end engineering. I can't tell if this a straight up adaptation of PERT 3-point estimates or

I worked on something similar[1] and was totally hamstrung by front-end engineering. I can't tell if this a straight up adaptation of PERT 3-point estimates or not. That's essentially what I was trying to develop. It's taught in project management courses but there're no simple tools for it. I'm wary of projecting from a few tasks to all tasks. The strength of the PERT 3-point method is that it can provide a projected cumulative distribution of outcomes based on expert opinion. There's a lot of PM and ops research literature about the PERT 3-point technique. My suspicion though is that it actually works less because of the quasi-statistical side of things, and more because of what psychologists called "the unpacking effect". The unpacking effect is simple: ask someone to estimate a task ("how long will it take to prepare for a flight across the country?"). The estimate will probably be low. If, instead you ask them to enumerate subtasks -- to unpack the task -- subsequent estimates become more accurate. I use this at work when estimating story points. See a story like "as a user, I can add a phone number to my profile", then speculate aloud what will be required. "We need a database field, to update the model, controller and view, we need some styling and documentation; does this need to be part of the analytics backend too?" Suddenly the 1 point story is 2 points, or 3. [1] http://confidest.com/ http://confidest.com/

halfcat 12y ago
>PERT 3-point estimates...It's taught in project management courses but there're no simple tools for it. Thanks for mentioning some theory behind this. What is lost by doing a simple best/worst/likely time estimate of all sub tasks, as compared to doing the full blown statistical analysis? The simple approach can be achieved relatively easily with a spreadsheet. For small-ish projects, does the full blown approach provide any significant benefit? I work mostly on small projects, implementing new server/network infrastructure for small/medium businesses. Time estimation is always a crap shoot, and the only approach I know to combat it is to pad the estimate with generic line items like "testing" and "troubleshooting". If the statistical analysis would help create a better estimate of time, I would spend time developing or contributing to an estimating tool.
- jacques_chester 12y ago
  > What is lost by doing a simple best/worst/likely time estimate of all sub tasks, as compared to doing the full blown statistical analysis? I'm not sure I understand you, but I'm just going to talk at you anyway. In the 3-point estimate you break the estimate down into smaller parts, then have experts assign best/likely/worst case values to each part. Then they are rolled up into a single CDF. The thing is that the formulae used are basically made up. They give a "triangular distribution", which superficially resembles a normal distribution at low precision. But lots of things don't resemble a normal distribution. You can hope that through the central limit theorem your estimate will improve towards resembling a normal distribution ... except that humans persistently underestimate everything. A lot of the Ops Research / PM literature is about fiddling with the formulae, or introducing adjustments based on historical data, which all helps. But by itself the 3-point method improves outcomes simply because you bother to enumerate stuff. The other secret is that if you do it a few times, you tend to look at previous estimates and you begin to remember things that are frequently forgotten. A common cause of underestimation is leaving off common tasks. For example, software developers can often give a reasonable estimate for the core work they're doing (code and tests), but tend to forget to account for everything else that's needed before a feature can be considered done done: merging, discussion with others, integration, deployments, documentation and so on.
  - halfcat 12y ago
    Thanks. So the main benefits are from simply enumerating sub tasks, assigning best/likely/worst case values, and repeating the exercise to improve sub task coverage. It sounds like the actual statistical analysis is only an incremental improvement beyond that, and probably does not add significant value to small projects.
    - jacques_chester 12y ago
      I don't know if anyone has checked.
geon 12y ago
> I worked on something similar[1] and was totally hamstrung by front-end engineering. Well, frontend is my thing, so... The estimation is a total hack, though. But it can easily be ripped out. > I can't tell if this a straight up adaptation of PERT 3-point estimates or not. It's probably not. I skimmed through some papers I found, but only to confirm the basic Idea I had to begin with. There is lots of room for improvement. > I'm wary of projecting from a few tasks to all tasks. Yes. This is intentionally just bullshitting. You are often very unsure of how big a task is going to get, and this bullshat number is sometimes as good as any number I can think of. And, sometimes the best way of getting the right answer is to give a wrong one. > My suspicion though is that it actually works (...) more because of what psychologists called "the unpacking effect". This is what I have noticed at work, and what I have (tried to) optimize the UI for.

halfcat 12y ago

>PERT 3-point estimates...It's taught in project management courses but there're no simple tools for it. Thanks for mentioning some theory behind this. What is lost by doing a simple best/worst/likely time estimate of all sub tasks, as compared to doing the full blown statistical analysis? The simple approach can be achieved relatively easily with a spreadsheet. For small-ish projects, does the full blown approach provide any significant benefit? I work mostly on small projects, implementing new server/network infrastructure for small/medium businesses. Time estimation is always a crap shoot, and the only approach I know to combat it is to pad the estimate with generic line items like "testing" and "troubleshooting". If the statistical analysis would help create a better estimate of time, I would spend time developing or contributing to an estimating tool.

jacques_chester 12y ago
> What is lost by doing a simple best/worst/likely time estimate of all sub tasks, as compared to doing the full blown statistical analysis? I'm not sure I understand you, but I'm just going to talk at you anyway. In the 3-point estimate you break the estimate down into smaller parts, then have experts assign best/likely/worst case values to each part. Then they are rolled up into a single CDF. The thing is that the formulae used are basically made up. They give a "triangular distribution", which superficially resembles a normal distribution at low precision. But lots of things don't resemble a normal distribution. You can hope that through the central limit theorem your estimate will improve towards resembling a normal distribution ... except that humans persistently underestimate everything. A lot of the Ops Research / PM literature is about fiddling with the formulae, or introducing adjustments based on historical data, which all helps. But by itself the 3-point method improves outcomes simply because you bother to enumerate stuff. The other secret is that if you do it a few times, you tend to look at previous estimates and you begin to remember things that are frequently forgotten. A common cause of underestimation is leaving off common tasks. For example, software developers can often give a reasonable estimate for the core work they're doing (code and tests), but tend to forget to account for everything else that's needed before a feature can be considered done done: merging, discussion with others, integration, deployments, documentation and so on.
- halfcat 12y ago
  Thanks. So the main benefits are from simply enumerating sub tasks, assigning best/likely/worst case values, and repeating the exercise to improve sub task coverage. It sounds like the actual statistical analysis is only an incremental improvement beyond that, and probably does not add significant value to small projects.
  - jacques_chester 12y ago
    I don't know if anyone has checked.

geon 12y ago

> I worked on something similar[1] and was totally hamstrung by front-end engineering. Well, frontend is my thing, so... The estimation is a total hack, though. But it can easily be ripped out. > I can't tell if this a straight up adaptation of PERT 3-point estimates or not. It's probably not. I skimmed through some papers I found, but only to confirm the basic Idea I had to begin with. There is lots of room for improvement. > I'm wary of projecting from a few tasks to all tasks. Yes. This is intentionally just bullshitting. You are often very unsure of how big a task is going to get, and this bullshat number is sometimes as good as any number I can think of. And, sometimes the best way of getting the right answer is to give a wrong one. > My suspicion though is that it actually works (...) more because of what psychologists called "the unpacking effect". This is what I have noticed at work, and what I have (tried to) optimize the UI for.