A forum for technical support discussion related to Fogbugz.
Hi all, I'm using FogBugz On Demand trial. We use Scrum as a development methodology.
Is there a best practice for FogBugz in terms of handling subtasks and grouped tasks? Usually, Feature items/cases are going to be fairly high-level, and we go through a Sprint Planning process where the high-level Feature is broken down into tasks 2 days in length or shorter for the purposes of effort estimation.
Ideally, we could make a particular case the parent case for a set of child cases which are the result of the task breakdown. What is the best way to do this in FogBugz?
Thursday, September 27, 2007
Here's how I would do it.
Say you have your main task and that is called MAIN and its case number is 34.
You're looking at a filter where you want your subtasks to be.
There is an Add Case link in the filter to do a quick add for cases.
I'd click Add Case and enter the title for all my subtasks, hit enter, repeat for next subtask. You'll notice they are all selected when you are done.
Hit the Edit button (or use the keyboard shortcut) to edit them all at once.
Write "Child of Case 34" and hit ok.
Now when you look at 34, all those cases will show as related to 34.
Don't enter estimates for your main task because it will be too large. Enter them for the subtasks and then you can use Evidence Based Scheduling to do your burn down charts too.
For your product backlog, just track them like cases, but put them into a release with an official release date that is later than your sprints (like a few months ahead) and name it Product Backlog. A simple filter for (area:"product backlog" orderby:priority) in the search box will show you everything (you can further refine the search by project, and even save that search to your filters).
Then each sprint becomes a mini release (by creating the fix for in FogBugz and setting the date on it). With FogBugz 6.0 this has the added benefit of showing you basically a reverse burn down chart. We will show you based on your estimates in chart form, the probability of shipping for that release. If your estimated date of finishing the sprint is close to the official date you set for the sprint, you'll see that. But you can also see if your sprint isn't going as quickly as you thought (or quicker than you thought). These charts are under Reports->[Project Name]
Michael H. Pryor
Thursday, September 27, 2007
This sounds like the system I've been using. But it seems to be slightly out of line with what Joel wrote on the blog today.
"2) Fix bugs as you find them, and charge the time back to the original task. You can’t schedule a single bug fix in advance, because you don’t know what bugs you’re going to have. When bugs are found in new code, charge the time to the original task that you implemented incorrectly. This will help EBS predict the time it takes to get fully debugged code, not just working code."
I'm writing new code right now. To follow Michael's example, say case CHILD is a child of case MAIN. I just was "working on" CHILD and resolved it in 30 minutes. In the example CHILD gets 30 minutes and MAIN gets 0.
If I'm following the blog entry, does this mean every time I resolve CHILD I should go and make a manual duplicate time sheet entry for MAIN? For example, if I resolve CHILD in 30, I duplicate that timesheet entry and apply it to MAIN. It seems like this would create weird scheduling results, because some things are being double counted. Also this involves eating some UI overhead, since "working on" only applies time to one case.
My suspicion is that ordinarily the double counting would be a bad idea, except for the fact that main has no estimate and thus has a different role in the time accounting/estimation?
I'm new and would love to hear what the canonical way of handling this is. Maybe I just have OCD, but tracking all this data is kind of addictive...
Thanks in advance!
You should definitely not be double counting. The main task in this case isn't really a case to which time is charged - it is only to organize the child cases. The only reason you might charge time to the main case is the time it takes you to determine what the child cases should be, but all time on those child cases should be charged to those child cases.
As an aside, I just discovered something that may help organize this in FogBugz for you - if you search for relatedto:<case number>, you'll get a list of all the cases related to a given case, and a nice summary at the bottom of the elapsed time spent and (unadjusted) time remaining. This could be handy for identifying all the child cases associated with a parent.
This topic is archived. No further replies will be accepted.Other recent topics