Question

Problem

I understand that the best way to use EBS is to always re-open your case whenever you find a bug or have to do rework, and continue putting time in against that original case until the task is finally and undeniably completed.

However, this doesn't work for us. We want to open and track bugs against the code we're writing. This provides a lot of value to us. - The problem is that new cases opened for these bugs don't count against the original estimate for EBS.

Scenario

• Developer opens a task to "code foo" and puts in an estimate of 10 hours.
  • Developer's estimation history is perfect. His variance from the estimate is 0%
• Developer takes exactly 10 hours to "code foo", resolves and closes his case.
• Tester tests foo and finds a bug. Tester opens a case for Developer to fix the bug (note that Developer could just open a new case, or any other method you could think of for generating a new case)
• Developer estimates that the case to "fix foo" will take five hours.
• Developer takes exactly 5 hours to "fix foo." He resolves and closes the case.
  • Developer's estimation history is still perfect. His variance from his estimate is still 0%.
  • The reality is that Developer was off by 50%! How do we show this without losing the value of opening a case for each bug found against the delivered code?

Proposal

My suggestion is to allow cases to be related to each other for the purposes of EBS. It could be the same level of user effort as entering a parent:

• Have a field called something like "Original Case"
  • This would have functionality like the parent/subcase fields where it would provide narrowed results while typing.
• Have all of the elapsed time from those cases count against the original estimate of whatever is entered into the the "Original Case" field.
• Have any case that points to an "Original Case" not count against EBS as the results may become skewed otherwise.

This allows us to capture valuable metrics such as how many bugs did we generate while writing each feature. Meanwhile, it also allows us to have really good EBS.

Case FC1856365

Answer 1

I think both the method proposed in the question and the method that cdeszaq is talking about are very valid ways to use EBS. I think Marc's method would work great if a team is trying to get bugfix time for each feature rolled up into the original estimate for the feature, and cdesquaz's approach if you're thinking about bugfix time in aggregate.

I think it would be great for FogBugz to support Marc's method via a 'Charge Time Against' case, and I think that now that we have the field selection UI in the left column of the bug edit view, we might be able to make this work without making the case too busy.

It would also work for cdesquaz's case if you wanted to still use a 'bugfix' schedule item but still capture information about which bugs took the time.

I have opened a feature request for this. Please up-vote the question above to show your support.

Answer 2

In essence, each bug found is a subcase of the original case, but the original time estimate is 0. Right now, you can't enter an estimate of 0 for any unit of time (but it would be nice!!!)

What you can do right now, however, is create a subcase for each bug, and then instead of charging time against the bug directly, you also have a BugFix scheduling item, and you charge the time against that.

In fact, including such a scheduling item for bug fixing or other block time that should be included in a schedule but is not necessarily part of any specific case, is considered a "best practice" because then you are scheduling for bugs in advance of them occurring. This will help to keep projects on track, because bugs don't add in unexpected delays (eg. expect there will be bugs), and if you end up with fewer bugs than you anticipated, wonderful...your project is done ahead of schedule, and you can then learn for future projects how much time to include for bug fixes.