Enable/Disable and Create Different Timeboxes
Problem to solve
Currently, there is no way to delineate the purpose of milestones in any sort of meaningful way other than the milestone name. As we're introducing the ability to assign issues to more than one concurrent timebox (#5135 (closed)) to support traditional planning methodologies such as Scrum, we need a way to identify what the milestone is from a data perspective so we can eventually add improved reporting across a given timebox type, auto schedule cadence for types, etc.
See this epic (&69) for the bigger picture.
This will unlock future enhancements such as:
- Auto moving issues from one milestone to another of the same type.
- Issues to be associated to both a sprint, version, or release simultaneously.
- Calculating velocity and volatility over
Current users are tracking sprints within GitLab, then exporting issues on a regular cadence to track longer run timeboxes like releases or projects. This will alleviate the need to work externally from GitLab to get this level of reporting.
- Add the ability to enable/disable three timebox types within a top level group's settings.
- Default is one enabled timebox named "Milestone". This cannot be toggled off. One timebox must always be enabled.
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 -
Types can't be deleted, just enabled/disabled.
Permissions and Security
- Stay inline with current milestones permission level of
- Yes, we will need documentation.
- To be determined during the implementation planning.
What does success look like, and how can we measure that?
- Count of timebox types being enabled and which ones are used most frequently.
- Proposal is generally satisfied.
- GraphQL first
- Rest API supported
gitlab-uifirst. If new components are required, add them there first.
- Telemetry added to capture success metrics.
Graph added to
Plandashboard in Periscope.
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