3 ms·

A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer. Over time you could bui

A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer. Over time you could build reasonable error bars around every engineer's estimations, and then sum the estimates _with the confidence intervals_ together and figure out the probability of achieving a certain ship date.

DocTomoe 5y ago
That's what Fog Creek Software's FogBugz tried to do. I liked it a lot, it also allowed for some team structure planning (e.g. giving you a chance to see if your team consists of pessimistic estimaters or positive ones, and mix accordingly). Unfortunately, their marketshare got gobbled up by Jira.
- noduerme 5y ago
  I feel like pessimistic estimators are way more accurate and probably more intelligent than optimistic ones. I'd probably use software like that to fire half the team. (edit: of course then I'd have to fire half the team again... and again... until only one or two incredibly depressed pessimists remained... tough call)
  - Jensson 5y ago
    Why would you fire the team? The software shows you how their estimates relates to real world timelines, just adjust their estimate accordingly and the problem is fixed. I never understood why managers get so upset over consistent time under estimates, just track it and add the relevant factor without telling the team and it should on average be on point.
    - noduerme 5y ago
      I was sort of just reducing the idea to absurdity. I only work in small teams - everything I do is by feel. It's easy to tell if things are behind or not. Easy to tell if someone is wasting time, or if they're stuck on a problem, and extrapolate a new ETA. Honestly, the idea of trying to feed that into software seems heartless and inevitably wrong, but if I were going to do it, I'd opt for the pessimistic analysis.
bojan 5y ago
> A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer. To do this you need to communicate very clearly why are you doing it, and if it will have any influence on performance reviews. But I do think that monitoring estimates in this way will affect the quality of estimates. A manager in my previous company noted everyone's estimations during sprint planning in an Excel sheet. No-one knew why, so I found myself thinking more about that Excel sheet than about making an well-founded estimation.

DocTomoe 5y ago

That's what Fog Creek Software's FogBugz tried to do. I liked it a lot, it also allowed for some team structure planning (e.g. giving you a chance to see if your team consists of pessimistic estimaters or positive ones, and mix accordingly). Unfortunately, their marketshare got gobbled up by Jira.

noduerme 5y ago
I feel like pessimistic estimators are way more accurate and probably more intelligent than optimistic ones. I'd probably use software like that to fire half the team. (edit: of course then I'd have to fire half the team again... and again... until only one or two incredibly depressed pessimists remained... tough call)
- Jensson 5y ago
  Why would you fire the team? The software shows you how their estimates relates to real world timelines, just adjust their estimate accordingly and the problem is fixed. I never understood why managers get so upset over consistent time under estimates, just track it and add the relevant factor without telling the team and it should on average be on point.
  - noduerme 5y ago
    I was sort of just reducing the idea to absurdity. I only work in small teams - everything I do is by feel. It's easy to tell if things are behind or not. Easy to tell if someone is wasting time, or if they're stuck on a problem, and extrapolate a new ETA. Honestly, the idea of trying to feed that into software seems heartless and inevitably wrong, but if I were going to do it, I'd opt for the pessimistic analysis.

bojan 5y ago

> A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer. To do this you need to communicate very clearly why are you doing it, and if it will have any influence on performance reviews. But I do think that monitoring estimates in this way will affect the quality of estimates. A manager in my previous company noted everyone's estimations during sprint planning in an Excel sheet. No-one knew why, so I found myself thinking more about that Excel sheet than about making an well-founded estimation.