Hello,
I'm setting up the schedules as a team lead for a new project and trying to use FogBugz as a primary scheduling tool. However, I'm unsure how to use FB appropriately to leave room for the incoming bug rate. I'm hoping project managers with more FB experience can help out.
In the past, I've collected the estimates of all the known items in the schedule, then padded those estimates to account for incoming bug rates (and meetings, etc). Then, because we work with a ZBR philosophy (fix bugs as they appear), the bugs fill in the padding and the schedule can be tracked by following the originally estimated items (with occasional modifications as needed). If the incoming rate is too high, the monitored items aren't being completed in a timely manner and the schedule shows the slip.
I don't see how to achieve that level of monitoring in FogBugz. Here's what I've considered:
set the % working or working schedule to apply the padding, but then incoming bugs instantly blow the schedule out, rather than filling the available space
leave a "stabilization" period in each milestone (ie, don't fill the milestone full), with explicit start/end dates on the milestone. This is the better option, but the predictions provided by FB will be way too optimistic initially...
do #2 above, but set the start/end date of the milestone to exclude the stabilization period and then use explicit bug (stabilization) milestones. I think that would give the most accurate schedule predictions, but likely be a pain to deal with the plethora of milestones and making sure bugs go to the right place, etc. Also, it wouldn't accurately reflect when the bugs should be worked on (bugs are fixed before stabilization, which may bump features into the time described as stabilization).
So, how do you handle this? Can I avoid breaking out ye'olde spreadsheet to achieve what I want?
Thanks,
gwagner
