A forum for technical support discussion related to Fogbugz.
More feedback after Day 1 with the new 6.x version of Fogbugz.
I am still trying to get my head around the system for how it converts hours to days in the estimates. I have to admit that in Fogbugz 5 I "disabled" this functionality by changing in the DB setting the number of hours per day to 100,000 so it basically always showed everything in terms of hours (ex 998H).
The reason I did this is that I didn't want to introduce confusion into the scheduling because of programmers adjusting the estimates based on other things going on. When a programmer is asked to enter an estimate in terms of total hours to complete it, they are thinking about the total working time. However, when I ask how many days they naturally start thinking in terms of deadlines and pad the schedule for vacations, meetings etc. Our problem, and it looks like the problem with the 6.x version is that by doing that it gets double counted.
Through some experimentation I found that the site schedule pretty much does the math on the hours now and sets the hours/day for everyone regardless of how the individual schedules for the assigned resource is configured.
The other concern I have is straight from the Fog Creek dogma. If you make it too complicated, people will work around it. The whole idea of timesheets seems a bit scary from that perspective. Our previous procedure was just to update the current estimate column to reflect the remaining time left and ignore the whole concept of elapsed time. Honestly, all I care about in terms of scheduling as a dev manager is how much time is left on the schedule. I realize the EBS might have some benefits in terms of accounting for the frailties of programmers in estimating, but it was good enough for me that having a revised daily estimate on open cases would converge on 100% accuracy. I just planned for the cone of uncertainty and moved cases in and out of the release cycle as we approached the point.
To end this novel, I am not sure at this point how we will, or if we will integrate the scheduling into our process. It is a pity because it looks pretty cool.
Friday, September 28, 2007
As you discovered, the hours to days conversion uses the site working schedule, not the individual working schedule, which is a bit confusing. I think the reason is that if I enter an estimate for a case and then assign it to you, it's unclear which conversion to use, so the Site Working Schedule is safest. But I agree it's confusing, especially since the estimate is always kept in hours in the database.
And you are correct that your developers may be double counting. However, EBS should be able to adjust for that, so long as they are consistently double counting (see http://www.fogcreek.com/FogBugz/docs/60/topics/schedules/Evidence-BasedScheduling.html for a whole slew of examples). The key is that whatever way they decide to do estimates and time tracking has to be done consistently for EBS to produce meaningful results.
As far as the complexity of these timesheets and estimating tools, we hope to improve on that. Fog Creek believes that the idea of understanding estimates as a probability distribution is a valuable one, and we'll work on adapting EBS to how our customers use this tool. While your solution of ignoring elapsed time may be the right way to get a release done in the short term, getting a better sense of how initial estimates relate to actual time spent on a case is necessary to improve long range planning. While you can still use FogBugz as you did with FogBugz 5, we hope that you give EBS a chance, as we think it will help improve project management with FogBugz.
This topic is archived. No further replies will be accepted.Other recent topics