We group and categorize tasks within a release under parent cases that reflect larger components/user stories/features/etc.
FogBugz does not now correctly calculate the Estimated time remaining for Parent Cases when some of the child cases have been resolved.
Currently, FogBugz takes a simple sum of the estimated time remaining for each of the child cases (regardless of resolved status). So let's say I have a Parent Case and child cases as follows:
2222 - Summary Feature -> 2223 - Task 1 (Est: 5h, Elapsed: 2h, Status:Resolved) -> 2224 - Task 2 (Est: 5h, Elapsed: 3h, Status:Active) -> 2225 - Task 3 (Est: 2h, Elapsed: 4h, Status:Resolved)
The actual expected time remaining on this Parent Case should be 2 hours (for the one remaining active case the estimate is
5 hours less the 3 hours worked already).
FogBugz will incorrectly (and somewhat naively) tell me that for this particular parent case I have 3 hours remaining:
3 hours [for Case2223 which is already resolved] + 2 hours [for Case 2224] - 2 hours [for Case2225 which is resolved but over estimate] -------------- 3 hours
So, the obvious fix here is to automatically set (for the purposes of this calculation) Estimated Remaining time = 0 hours for those cases that have already been resolved. It only makes sense. Just because I went over on one case in a parent group doesn't mean that it will suddenly not take as long to finish the other cases. Similarly, just because I'm under-estimate on cases in a group doesn't mean that it will magically take more time.
I understand that this doesn't affect EBS. But for purposes of reporting and looking at completion effort for individual feature groups, this is dramatically misleading.
It's bugged me (no pun intended) for a long time and I've already developed my own reporting for rolling up Feature/Parent groups and getting correct estimates for them, but I just ran into it again and wanted to put it in here.