Like many FogBugz features, you can use this feature in several ways (and likely in ways we haven’t even considered, yet). That being said, there are two main methods we see people using effectively:

#1 – Like You’re Building a House, but Digitally

Use milestones as markers for… well, milestones: Big, specific, achievable goals. Depending on your release cycle and style, you may have start and completion dates for these goals. I recommend setting a completion date at least to get the most advantage from Evidence Based Scheduling (EBS).

When you’re creating these milestones, remember that you’re grouping a set of cases that apply toward a common goal. It’s a delicate balance that ties back to how you break down work in the first place. That discussion is far beyond the scope of this post, but suffice to say that if you have a case that fits into two milestones, then either your milestones are too small in scope, or the case is too large in scope.

One solution to this problem is to break that case into subcases that fall in different milestones. The parent case can then go into a milestone like “30,000 Foot View”. These cases don’t have any work, and only inherit summed estimates from the children. Once all the children are done, they get closed without ceremony… But it does keep everything organized! The “30,000 Foot View” milestone shouldn’t have a start or end date on it (because it isn’t really a goal in and of itself, just a summary).

By the end of this process, you end up with several milestones that probably have somewhat disparate completion dates. Each milestone has a unique collection of cases which, when completed, whatever the goal of this milestone was will also be completed. As you put estimates into cases and complete them, EBS should give you an accurate picture of how these milestones are doing.

#2 – Now You’re Thinking in Sprints

This is the sprint-based workflow, typically some form of Agile/Scrum. Now, milestones aren’t (necessarily) specific goals or objectives in your product’s creation. Instead, milestones reflect periods of time (typically two weeks long) which has a goal in itself: Complete all of the cases assigned to that sprint. Maybe those cases get you to a new plateau… but maybe not. It doesn’t matter: You have two weeks of work to do, here’s when you start, and here’s when you end.

You start thinking about milestones in the middle of this process. You’ve already created the cases necessary to complete the project (or at least a few sprints worth), applied estimates, broken into subcases, and then thrown them into a backlog that roughly approximates the order you want them done in. Now all you need to do is decide how much work your team can actually do in two weeks. Let’s say you have 5 devs who will always give you exactly 8 hours of work per day because they’re robots or… magic? I guess? In any event, you can confidently complete 400 hours of work every two weeks.

You create a milestone for “Sprint 1”, give it a start and end date, then put 400 hours worth of cases into that milestone. Your developers divide up the work, and have at it. While they do that, you line up the next few sprints. After a couple sprints, EBS should be accurately predicting how good or bad the situation will be based on how good or bad you’re proving to be at estimating those hours in the first place.

But Wait, What’s the Deal with Global Milestones?

First, if you find yourself in a position where you have a case that needs to be in two projects, think very carefully about whether you’ve gone wrong in how you structured your projects. This kind of thing happens, but it shouldn’t happen often. Maybe a translation project is in order?

Now that you’re sure you’re doing the right thing: Global milestones are milestones which can take cases from all projects. A case can still be a member of only a single project and only a single milestone, but you can have a single milestone that encompasses cases from more than one project. How does this fit in with the above?

With a sprint-based workflow, this is incredibly easy: They are cases in a sprint. Just do them and everything will work out. No need to be fancy, here! Maybe you had to temporarily join two teams to work one sprint… no big deal, just do that. The beauty of the sprint-based workflow is that this just works. But I submit it should be rare you need these global milestones or they’re going to be regular and predictable like “Build Week Sprint” to finish up several projects at once and get them out the door.

If you’re building a house, this takes a little more thought. Why are two of your houses interacting? You have cases in two projects that need to be grouped as part of a single goal. It’s one thing to have parallel constructions and releases, but for that you should have two regular milestones with the same completion date. A global milestone in this context means that you have a goal that spans two projects in such a way that one project completing their work would be meaningless without the other project doing the same.