For each feature in FogBugz, you have to decide when you want to implement it. Similarly, for each case, you have to decide when it’s going to be fixed.
In FogBugz, this is done by assigning a particular milestone to a case. 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”).
In an agile project, milestones could be used to represent sprints where the end of the milestone represents a commitment for having certain work done as opposed to an actual checkpoint in the development process.
To edit milestones in a particular project, you have to either be a site or project administrator. From the Avatar menu, 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 (EBS). 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 its 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 a 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 a pre-defined global milestone. You may also want to add “ASAP” or “Never”. To edit these global milestones, go to the Avatar menu > 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 unassignable automatically because the last thing you need to worry about during crunch time is why a milestone has suddenly disappeared from your dropdowns.