A forum for technical support discussion related to Fogbugz.
We currently use FogBugz simply for shifting bugs between test and development.
We would like to also use the estimation and prediction features and have run into a problems:
- We create a plan for the work (whatever it may be). It contains: Spec, Code, QA, Deployment (much finer granularity in practice). Each item is estimated.
- We enter these into FogBugz including estimates and FogBugz confirm total time. All good
- We use the "Working on" feature to compute actual time. This is fine too. We get some nice graphs now.
- The first test-round starts, and our test-team starts firing bugs into FogBugz.
- The developers start putting estimates on the fixes - and now things start going astray..... The original estimate already catered for bug-fixing so the total estimate now start expanding. That wasn't really meant to happen.
We clearly don't use the tool in quite the right way.
My question is: What is the recommended way to use the tool?
Thanks in advance,
- Mads -
Tuesday, May 12, 2009
As you pointed out, you are double-counting your bug fixing estimates.
I think that the recommended way is to either:
1. Enter your Bug Fixing time as a schedule item (i.e. we will spend the month of May fixing bugs) and don't enter estimates for each bug you find.
2. Don't enter one estimate for fixing of all bugs, but instead enter an estimate for each bug as it is found.
Either method could be valid, depending on your particular project. For example, if you know you have an inflexible ship date that you absolutely must meet, then use the first method, but if you plan to not release your product until a majority of the bugs have been fixed, then use the second method, which will show you when you will ship, based on the number of bugs remaining and the estimates for each.
Hope this helps.
It would make sense to me, NOT to include the "bug fixing" time in the initial case/estimate seeing as you have no idea:
1) if there will be any :p
2) what they'll involve
3) how long they'll take to fix
I'd estimate getting the feature in and working, fire off to testing who then submit a new bug which is estimated based on its info.
Thanks to you both.
I think we will go with the pragmatic approach: Decide on a project-by-project basis. We run both types of projects.
Wednesday, May 27, 2009
This topic is archived. No further replies will be accepted.Other recent topics