Should cases be reopened for bugs, or should bugs be opened as a new case?

Question

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?

Answer 1

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

Answer 2

If this is all happening before the feature is released to the customer then just have one case. The argument here is that the case isn't truly complete until it's passed QA and ready to be released. The other benefits - a single case number for the billing and end users to reference are valid and important.

Once the feature has been released and bugs are found these should be raised as new issues in your issue tracking software.

Answer 3

I agree with you completely, and so does FogBugz - that is why it defines different categories for Bugs and Features. FogBugz was not designed to be a tool to track time use; this is an accidental byproduct of the introduction of evidence-based scheduling.

Bugs for a completed feature can be linked to the main case for the feature (in FogBugz, by use of a tag name, or a cross-reference, or by making them sub-cases). I can see that this is a bit more work for your PM to consolidate information across several cases, but it often also makes sense to be able to separate time spent on original development and time spent on maintenance, especially for fixed-price contracts, and you lose the ability to do this if you put everything into one case.

Answer 4

Its my opinion that once a ticket is closed it should stay closed, your bug tracker should be capable of linking to other cases anyway. I would try to point out that creating new bugs and linking them to the original case provides better benefits than the method you describe.

• clients can still have one reference number that contains links to each bug.
• each bug's status can be individually tracked, allowing for better prioritization and status reporting.
• having separate bugs will allow you manager to break down time spent on bugs vs time spent developing new features, and should only be a minimal additional effort to get a total number for all bugs related to a change and the development of that change.
• separating bugs makes it much easier for your manager to gather other metrics like total bugs, average time per bug fix, ratios of closed/in progress/fixed bugs.
• separate cases per bug allows tasks to be better divided between all developers and hold each accountable for their own work, or allows this possibility should more developers be hired at a later date.

The only advantage to your current setup is that its extremely simple for the people who aren't the main users of the system. The purpose of a bug tracker is for the developer to have a place to report everything about a bug in a single place that also happens to be friendly enough for others to see the progress, your current system seems to undermine almost every part of that.

Answer 5

Are the bugs found before or after the product has been 'shipped/released' to customers?

If it is before a release, the bugs should tracked against the original ticket.

If it is after a release, each bug should be its own ticket.

Answer 6

Where I work, only the QA people can close a case. We have checkboxes for Code Reviewed, Engineer Tested, and Demo to Stakeholder (in your case Project Manager). If the QA team sees a case marked as "Done" which doesn't have all of these fields marked, they will mark it undone and send it back to us.

Once a case has passed all these phases and QA closes the case, any new issues they find are logged as bugs.

This system seems to work well for us.

Answer 7

I think you can make an argument both ways. I would try to sit down with the PM and explain why you think having discrete issues will help you out. I personally want each todo item should be its own ticket but I can see why he wants it that way.