Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
1  
possible duplicate of Bug reopen vs. new –  FrustratedWithFormsDesigner Apr 18 '12 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 –  Joachim Sauer Apr 18 '12 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? –  Joachim Sauer Apr 18 '12 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). –  Joachim Sauer Apr 18 '12 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 '12 at 17:36
show 3 more comments

7 Answers

up vote 10 down vote accepted

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.

http://i.stack.imgur.com/ng4jn.jpg

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.

share|improve this answer
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 '12 at 21:46
    
@Tacroy thanks - I updated the answer –  gnat Apr 19 '12 at 11:22
    
+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 –  Curt Apr 20 '12 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 '12 at 12:28
add comment

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.

share|improve this answer
    
+1 Emphasis on, 'before the feature is released'. –  Evan Plaice Apr 18 '12 at 16:26
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 '12 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 '12 at 20:57
add comment

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.

share|improve this answer
    
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? –  Curt Apr 18 '12 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 '12 at 15:41
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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