Software Engineering
- project-management development-process issue-tracking
- Updated Sun, 17 Jul 2022 15:40:53 GMT
-
Should cases be reopened for bugs, or should bugs be opened as a new case?
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?
Solution
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.
Comments (3)
- +3 – FogBugz supports subtasks - make one case per bug, and then assign the original case as each bug-case's parent. It'll even sum up the total amount of time you spent per bug plus parent, while also individually tracking each individual bug case's time spent. — Apr 18, 2012 at 21:46
- +0 – +1 Thanks gnat, this is a great help in my argument for use of seperate cases for bugs, and how they can still be linked to the original feature — Apr 20, 2012 at 12:15
- +0 – @Curt good luck. Keep in mind this has a lot to do with correctly picking your battles. Whatever they insist on having in "parent task", don't fight too hard - let them hang on their own rope. Your sub-tasks are your fortress - these should be your line of defense. Btw you might really need to defend it - the very fact that your manager was unable to figure that solution, makes me wonder if they are sufficiently qualified in tracking dev efforts — Apr 20, 2012 at 12:28
External Links
External links referenced by this document:
Linked Articles
Local articles referenced by this article: