Multiple milestones per issue or merge request
Problem to solve
There is no way to associate an issue to more than one concurrent timeboxed milestone. This is particularly problematic for teams that practice modern flavors of Scrum or ExtremeProgramming.
The most common use case:
- An issue is part of a shorter sprint (1-4 weeks).
- Which also rolls up to a longer "release" (1-3 months).
It is impossible to track the completion progress against both timeboxes.
Most likely personas that will benefit from this feature:
Since we require a milestone for a upcoming version of a given project it is a big pain that we can't attach another milestone for a given release window.
😢Workflows with multiple projects and additional operation tasks are usual today even for small teams so it would be nice if we had the tools to properly plan and observe them.
The reason we need multiple milestones attached to an issue is that we would also like to create a milestone for our 2-week sprints. So an issue would be part of our SOW milestone for SOW Project Management over a timespan of a month or so, as well as our sprint plannings for our current working schedule.
It feels like I spend a lot of time trying to organize issues spanning multiple projects and multiple stakeholders trying to avoid the single milestone limitation. We end up using labels as a poor replacement.
Bigger Picture Goals
- Issues and Merge Requests can be tracked across multiple milestones simultaneously (this issue).
- Milestones show historically accurate data (#5135, #6903, #26690, #24848)
- Milestones can be associated with a type so that it is easy to understand which milestone maps to which business process.
- Milestones can be set on a configurable, recurring schedule so that maintaining release planning and sprint cadence is more automated than manual.
- Allow users to associate up to five milestones to an issue or MR. This will be more than sufficient for smaller teams and also support the typical "layers" within larger organizations that use enterprise agile frameworks.
- Properly handle the UX for displaying multiple milestones in the issue, issue search list item, epic, and any other locations where a reference to an issue also displays the associated milestone.
Permissions and Security
- They should be consistent with the existing permissions structure regarding which roles can update milestones within a given Issue or MR.
- We should probably update https://docs.gitlab.com/ee/user/project/milestones/index.html#overview and maybe even consider removing milestones as a child of Issues as we currently have both project and group level milestones (or making it more discoverable from either navigation menu).
- As part of this issue, we will have to determine how having multiple milestones on a given issue impacts the dynamic setting of start and due dates on epics (https://docs.gitlab.com/ee/user/group/epics/#start-date-and-due-date).
- We should consider putting this behind a feature flag during development.
What does success look like, and how can we measure that?
- Quantitative - Count of issues with more than one milestone.
- Qualitative - Feedback from the wider community.
- Basic behavior of the proposal is satisfied.
- Uses GraphQL.
- Public APIs updated.
- Uses Pajamas.
- Necessary telemetry for measuring quantitative success metrics is implemented.
What is the type of buyer?
Based on our current understanding, any reasonable manager that is utilizing modern agile planning practices would buy this feature. Based on our four pricing tiers, this would fall into the GitLab Starter tier.
Links / references
- Problem 2: Users (customers have expressed this problem) want a particular feature to be exposed to multiple releases, so that various stakeholders who care, can know. For example, a single change in a backend service benefits the mobile app and a web app. The mobile app people want to expose that change to the mobile app stakeholders, and same for the web app. This is currently not possible in GitLab since an issue can only be associated with one milestone. So that issue/feature cannot be readily exposed to multiple releases.
- Support assigning multiple milestones per issue or merge request.
- This is a boring solution since it doesn't require us to invent a brand new field/attribute for issues/mrs. Furthermore, if you do invent a brand new field/attribute, you have to worry about naming/re-naming which is a big problem. And also, milestones are already deeply integrate with issues, mrs, boards, and other places in GitLab. If we invent a new attribute/object, we would have a lot more work ahead of us to integrate that into all the other places in GitLab.
- By allowing for multiple milestones per issue/mr, we instantly have all the benefits of GitLab, but now users can support additional workflows and solve their problems.
- Also, we trust users to be careful and know when they are using a milestone to indicate a sprint/iteration versus a release. (For the case of GitLab, it doesn't matter since it is 1-1.) So for example, if you are using a milestone to represent an iteration/sprint, you would assign a start date and end date to the milestone. And you would use the burndown chart to observe the sprint/iteration burndown. But if you use a milestone as a release, you would only use the end date of the milestone to represent the release date. You likely wouldn't use the burndown chart because it wouldn't make sense in that context. This design reduces the complexity of GitLab by allowing us to use milestones for multiple reasons.
Design artifact scope
- Consider if this is a good solution for solving the problem of having separate
- If this is a good solution, consider all the UI that needs to be changed, system notes, quick actions, notifications, how to indicate multiple milestones in issues and merge requests.