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?

  • 1
    possible duplicate of Bug reopen vs. new Apr 18, 2012 at 15:12
  • 2
    I don't think that this is a real duplicate, its similar, but there's an important difference: Here it's about a new feature being implemented and a relatively short round-trip time back to the developer. The answer might (or might not) be similar, but the question is different Apr 18, 2012 at 15:17
  • 1
    But maybe I misread this. Are the bugs found by QA/before a release was done? Or is this a "several months later"-case? Apr 18, 2012 at 15:18
  • 2
    @Curt: that doesn't really change the fact that he shouldn't close the ticket unless he's certain that it's Done (for whatever your definition of this is). Apr 18, 2012 at 16:13
  • 3
    You could open child cases of the main case for tracking, they will all be listed with the main case when you search for it
    – JF Dion
    Apr 18, 2012 at 17:36

7 Answers 7


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.

  • 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.
    – Tacroy
    Apr 18, 2012 at 21:46
  • +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
    – Curtis
    Apr 20, 2012 at 12:15
  • @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
    – gnat
    Apr 20, 2012 at 12:28

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.


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.


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.

  • I mostly agree with the "closed ticket should stay closed" bit, but there are always exceptions, such as if a bug is reintroduced, as can happen with a rollback (or worse, if part of a project is lost and needs to be restored from backup).
    – zzzzBov
    Apr 18, 2012 at 20:53
  • @zzzzBov those are pretty significant exceptions, and if you find yourself in that position I doubt how you handle bug tracking is a concern at that point.
    – Ryathal
    Apr 18, 2012 at 20:57

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.

  • We copy the application to a development server where the client can access the site. Sometimes the bugs are found internally, sometimes they are found by the client. Are you suggesting the bugs found internally (by PM) mean the case should be reopened and the bug attached to the bottom of the case/ticket?
    – Curtis
    Apr 18, 2012 at 15:34
  • If the bugs are found before release, they should be treated as if the feature was not completed. See the answer from ChrisF.
    – Colin D
    Apr 18, 2012 at 15:41

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.