Question

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).

HOWEVER,

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.

Answer 1

Thanks for bringing this up! Sorry this went so long without a reply.

This is, unfortunately, a little more complicated than simply a bug which isn't properly clearing the remaining time. You'll notice that we exhibit the correct behavior when a subcase is closed (mostly; the "Elapsed Time" column has a real summation bug in it that I filed last week).

The issue is because FogBugz workflows can be, arbitrarily, split into two types:

1) Resolution Light/Activity Heavy 2) Resolution Heavy/Activity Light

The difference between them is that in the first one, "Resolved" means that the case is done but there may be some extra clean-up work to be done. However, that extra work is either sunk time or so short as to be meaningless. In short: Resolved very closely resembles Closed. In this case, it makes perfect sense to clear the remaining time as you indicate.

The second one is typically seen when "Resolved" means "whomever just had this case is done with it." This leaves the possibility that someone else has work left to do on it. The most glaring example of this is when a developer implements a feature and then resolves it as something like "Resolved (In QA)", and they then resolve it as "Resolved (Verified)", and then the tech writers resolve it as "Resolved (Documented)".

Regardless of which you feel is best, there are great arguments on both sides. Each project manager will have that "killer" argument that settles it for them, but there isn't a killer argument that makes one necessarily better than another in all circumstances.

It's entirely possible our design choice may not have been the right one. There's a lot of food for thought here, so I've filed a case for us to discuss this internally and try to decide if we made the right choice. If we can find an acceptable compromise, that would be ideal, of course.