This is a work in progress for the Marketing Project Management Simplification project.
There are two concepts of time-based tracking in GitLab.
Milestones are a great way to track the progress of multiple related issues across a specific time period. With milestones, you can see how fast issues are being completed in that time period (burndown chart), and you can view the issues grouped by labels, and grouped by status (unassigned, assigned, and completed)
Milestones are very useful when tracking the progress of multiple issues and when planning and managing epics.
Here are two examples of milestones:
Define milestones at the LOWEST level of the organization as possible.
This will mean that the lists of milestones available to a given Issue (when adding an issue to a milestone) will be limited to a smaller list of relevant milestones. (though the list might still be very long)
Because of the filtering limitations and the massive volume of potential milestones, a consistent Naming Convention is very, very, very helpful in finding the right milestones.
This will help in two ways. First, when looking at lists of milestones, they can be sorted and put the related milestones together. Second, in issues, when adding a milestone, you can search by name, which will make it easy to find the right subset of milestones (either for the project or group)
Because the milestone does not yet include change history or details about who created it or why, we should use the description field to fill in the blanks.
marketinggroup for executive topics and integrated campaigns.
Recommended dates and duration: it depends, though shorter is often better. Because the milestone has dates for start and finish, the implication is that issues and MRs in the milestone are completed in this time window. If the milestone window is 3 weeks, then the expectation is that the work in the milestone is completed in that time frame.
Every team and every project is unique and there is no one answer for milestone duration. Some teams have had milestones as long as a quarter, others 4 weeks and others 1 week. Choose the duration that works for your team, learn, and evolve.
Define iterations at the HIGHEST level required of the organization as possible (for a cohsive approach using the same time-basis).
A consistent Naming Convention is helpful to ensure similar iterations (i.e. not including
Mktg: are used by only the Marketing department at GitLab.
Mktg: YYYY-MM-DD, with the ISO-formatted date being the end date of the milestone.
Mktg:allows for filtering to only the Marketing-wide iterations, and the ISO date can help further filtering on month/day when assigning the milestone to an issue.
marketinggroup, essentially for executive topics and integrated campaigns, but it is encouraged that all groups in Marketing use this one set of iterations for a unified workflow. These are the only iterations that will be defined at this level.
marketinggroup. When scheduling backlog issues on an issue board or on an issue list, the backlog can be further filtered by team.