Assign an issue to more than one timebox (Milestone & Iteration)
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.
Intended users
Most likely personas that will benefit from this feature:
Further details
Use Cases
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.
Proposal
Bigger Picture Goals
- Issues and Merge Requests can be tracked across both a milestone and an iteration (this issue).
- Milestones & Iterations show scope changes and better reporting of what happened during the milestone (Epic &1957)
- Milestones/Iterations can be set on a configurable, recurring schedule so that maintaining release planning and iteration cadence is more automated than manual. (Epic: &69)
This Issue's Scope
- Allow users to assign an issue or MR to both an iteration and a milestone. 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 milestones and iterations in the issue.
- Properly handle fringe cases
UX Summary (detailed descriptions in the image)
Iterations will be active by default and have their own place in the left navigation under Issues. Creation of a new iteration will be similar to milestone creation and they will have their own list view, also similar to milestones. Issues can be added to an iteration by navigating to the issue and selecting the iteration from the right sidebar.
Not in scope
Enabling and disabling timeboxes via a group's settings will be handled in this issue (#35290 (closed)).
This epic (&2422) is tracking improvements across the product to support the the reality of issues and merge requests being assignable to more than one timebox.
Fringe Cases
1. When an issue moves to another a project or group that does not have the same timebox types enabled:
Prompt with a warning dialogue - You are moving an issue into a group that does not have X, Y, and Z timebox enabled. These will be removed from the issue if you continue - Move Anyways Cancel
Permissions and Security
- They should be consistent with the existing permissions structure regarding which roles can update milestones within a given Issue or MR.
Documentation
- 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).
Testing
- As part of this issue, we will have to determine how having issues on multiple timeboxes 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?
Success Metrics
- Quantitative - Count of issues with more than one timebox.
- Qualitative - Feedback from the wider community.
Acceptance Criteria
-
Basic behavior of the proposal is satisfied. -
Epics dynamic dates work correctly with multiple milestones per issue. -
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
/label feature
Old Description:
- 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.
Proposed solution
- 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.