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.

Intended users

• Parker (Product Manager)
• Delaney (Development Team Lead)

Further details

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 n previous timeboxes.

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.

Proposal

Summary

• 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.

Fringe Cases

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

Deleting types....

Types can't be deleted, just enabled/disabled.

UX

Discussion regarding the proposed UX

Permissions and Security

• Stay inline with current milestones permission level of Developer and above.

Documentation

• Yes, we will need documentation.

Testing

• To be determined during the implementation planning.

What does success look like, and how can we measure that?

Success Metrics

• Count of timebox types being enabled and which ones are used most frequently.

Acceptance Criteria

• Proposal is generally satisfied.
• GraphQL first
• Rest API supported
• gitlab-ui first. If new components are required, add them there first.
• Telemetry added to capture success metrics.
• Graph added to Plan dashboard 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

• None

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.