Currently at my work place we use FogBugz for managing all our features and bugs for our different web applications.
When a new feature is to be added to one of our web applications, a new Case is created. For example "Create CSV Upload Form".
I then work on the case recording the amount of time I've spent on it. Once this case is completed, I then resolve it, and it gets assigned back to the case opener (usually the project manager), who then closes the case.
If there are any bugs with the feature, my Project Manager then re-opens the case, and assigns it back to me with a bullet point list of bugs.
In my opinion I believe these bullet pointed bugs should be opened as individual bug cases, so that they can be tracked easier, and not get cluttered with the original feature case notes.
My managers disagree with me stating that it is easier to work out the total time spent on the feature if its all in one case.
Furthermore they believe it is less confusing for our clients as they only have 1 case number reference for the feature. However I would stress that the bugs should be dealt with as seperate cases as this is post-completion of the original case.
Am I right in stating that bugs should be reopened as a new case? And what are the pros/cons of each way of managing this?
Both you and your manager have good reason for dealing the way each of you prefer, and there is no real need to compromise. There is a solution that works for me and addresses both concerns.
For cases like yours I use high level task / low level sub-tasks approach (concept I picked from JIRA, can't tell if FogBugz support it explicitly looks like it does). This way, "client-facing" bulleted lists go to high level tasks while "developer iterations" that are important for me are reflected in sub-tasks.
When high level task is "reopened", I create a new sub-task to track the added effort for self.
That way allows developer to clearly reflect all the permutations, perversions and twists passed through by feature specification, still letting manager to present it to clients as-if-perfect. By the way as-if-perfect presentation has its value to me as developer - because having it easier to read for clients helps in getting more accurate adjustments.
This also naturally allows to have a clear justification in cases when feature implementation takes much more time than anticipated originally.
As for time tracking per task or sub-task - since JIRA allows to include sub-tasks tracking into higher level summary, it is acceptable for manager that I track time in sub-tasks. However, even if this would be not the case, I could live with formally tracking time in "parent" task - in this case I would just use sub-tasks comments to state how much time has been spent on particular iteration.
External links referenced by this document:
Local articles referenced by this article: