For each feature tracked in Manuscript, 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 Manuscript this is done by assigning the case to a particular milestone. By default, every instance of Manuscript has an Undecided milestone as a catch-all. To harness the power of Manuscript, 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, 8.1, 10…)
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. Navigate to Avatar menu > 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/2018. You can move the date at will (although your management may be less flexible than Manuscript 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 Manuscript 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 stuff for earlier milestones before you do any of the stuff for later milestones. 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.
Although milestones are normally per-project, you can also create milestones that can be used for any project. We call these Global Milestones. Manuscript ships with “Undecided” as a pre-defined global milestone. You may also want to add “ASAP” or “Never”. To edit these global milestones, an administrator can navigate to 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 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.