Milestones

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.

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 insane, 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, ...)

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").

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.

To edit milestones in a particular project, you have to either be a site or project administrator. From the Admin menu, choose Projects. Click on the project name and scroll down where you'll see a section marked Milestones (this project).

Each milestone has a date; 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!)

• 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. See Release Notes.

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. FogBugz ships with "Undecided" as a useful default milestone. You may also want to add "ASAP" or "Never".  To edit these global milestones, go to the Admin menu 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.