Question

when looking at a series of bug assignments/reassignments found here : http://www.fogcreek.com/FogBugz/docs/70/topics/basics/Thebasicsofbugtracking.html

the first person that sets the time estimate gets the time 'billed' to them when work starts [right?], but when cases get passed around and reassigned to various groups [dev, test, etc], should time estimates or 'working on' even be used?

note: the image at the url above doesn't have any time estimates.

Answer 1

Let me expand on @cdeszaq already excellent answer with an opinion of my own.

You should strive to let the people that will perform the tasks do the estimates.

The reasoning behind this is that their experience, which is what is going to help them complete the task, is different from other peoples experience, and thus different people might take a different amount of time to do the same thing.

Rarely will you have a homogeneous enough team that everyone does things the exact same way and at the exact same speed.

Thus, passing a case around between multiple people should probably not be done.

Instead, let a parent-case be without an estimate, split the case up into chunks, that you then dole out to different people, and let them estimate their own case. This way, each person estimates only what he/she will be doing, and the parent case gets a good nice total estimate from the sub-cases. Then you don't need to pass anything around at all.

Now, of course, if you actually need to pass a case on to someone else, for instance because someone called in sick and you can't wait for them to return to work, then you pass it on, but that's a different issue.

If you simply want to pass a case around because the work really needs to be split up and doled out to different people, use sub-cases.

Answer 2

The time estimate actually gets "set" to the person who most recently entered an estimate prior to time being entered against the case. (I'm pretty sure of this, but someone please correct me if I'm wrong).

In the image you linked to, the case gets passed around, but only 1 person (Mikey the Programmer) is actually doing the work of the case (ie. fixing the bug). The other assignees are simply responding to things and not really putting in any time (or at least not much) to deal with resolving the case.

That being said, initially we too wanted to simply pass a case around if multiple people each had a part to play in completing it. Given the way FogBugz time tracking works, however, you noticed that this sort of workflow isn't really how the system is set up. After some initial struggles, we noticed that in scenarios where you feel like you want to "pass it on", really there is more than one task that needs to be done but there is a dependency relationship between the tasks.

To handle this, we use the powerful sub-case feature of FogBugz. This lets us take a particular case and wrap it in super/sub-cases in a chain-like hierarchy that shows the dependencies between the different tasks, who is responsible for the various "stages" and also lets us track time against each piece of the puzzle. We've found that this keeps things quite a bit cleaner, gives us (and the FogBugz scheduling system) more data on how things are working, and also gives us smaller chunks to work on so things don't get so overwhelming. For us, the benefits of doing it this way greatly offset the small additional overhead needed to plan things out a bit more clearly.