For each feature in FogBugz, you have to decide when you want to implement it. Similarly, for each bug, you have to decide when it’s going to be fixed.
In FogBugz this is done by assigning the case to a particular milestone. By default, every instance of FogBugz has an Undecided milestone as a catch-all. To harness the power of FogBugz, we recommend moving cases out of this milestone as soon as feasible into an appropriate Project-level milestone.
Milestones can represent goals, though how you set those goals will depend on your workflow. For example, a milestone could represent each major version of your software, whatever numbering scheme you use: 1.0, 2.0, etc.
(Or, if you’re really creative, you can use a simple and obvious numbering system like 1.0, 2.0, 286, 386, 3.0, 3.1, 3.11, 95, 98, 98SE, Me, XP, Vista, 7, 8…)
You can also use milestones to track minor versions (Alpha, Beta 1, Beta 2, Release Candidate, Gold Release, Service Pack 1, etc.) or checkpoints in the code development process ( “Search feature code complete” or “Performance work and optimizations”).
To edit milestones in a particular project, you have to either be a site or project administrator. From the Admin menu (or if you’re using FogBugz Ocelot click ), choose Projects. Click on the project name and scroll down where you’ll see a section marked Milestones (this project).
When a certain milestone is coming up, you can create a filter to see all the features and bugs that need to be fixed for that milestone. Each milestone can have a completion date as well; for example, the 2.0 alpha release might be planned for 6/4/2007. You can move the date at will (although your management may be less flexible than FogBugz about changing dates!)
Filters will order Milestones as follows:
- The Global “Undecided” milestone
- Global milestones without completion dates, in alphanumeric order
- Project milestones without completion dates, in alphanumeric order
- Milestones with completion dates, in date order
Also, note that your “official” dates that you enter for a milestone are not the same as the dates that FogBugz will calculate later using Evidence-Based Scheduling. As far as EBS is concerned, the only thing that matters about official dates is their order. It will assume that you’re going to do all the “search feature milestone” stuff before you do any of the “alpha” stuff because it comes first, officially. But EBS will have it’s own opinions of when you’re going to finish, based on your estimates, not based on the official date.
When you fix a bug or implement a new feature, before you resolve the case, double check that the milestone is correct; that way it can also be used as an historical record of which bugs were fixed in which milestone, and which new features were implemented for which milestone.
FogBugz also lets you maintain and create Release Notes automatically.
You can also create meaningful milestones without dates.
Although milestones are normally per-project, you can also create milestones that can be used for any project. We call these Global Milestones. FogBugz ships with “Undecided” as pre-defined global milestone. You may also want to add “ASAP” or “Never”. To edit these global milestones, go to the Admin menu (or if you’re using FogBugz Ocelot click ) and choose Projects. Click on any project name and scroll down where you’ll see a section marked “Milestones (all projects).”
After all work for a milestone has already been completed, it doesn’t make any sense to assign new cases to it. You should set the “Assignable” field of the milestone to “No” to prevent new cases being assigned to a completed milestone, which also makes the “Milestone” dropdown shorter so it’s easier to enter new cases. We make this a manual setting, rather than making milestones become unassignable automatically, because the last thing you need to worry about during crunch time is why a milestones has suddenly disappeared from your dropdowns.