Spike: Assign a Milestone to an Epic
Summary
We will add Milestone to the epic level so that Product Managers and other planning users can use this feature for longer planning horizons.
In order to plan from a high level, users need to be able to build out Milestones that represent a longer time frame (weeks, a release schedule, quarters, even a fiscal year) and assign high level Epics to them... like a feature Epic or major project Epic to represent the businesses general plans of execution. From there, product and engineering can begin breaking the work into sub-Epics and Issues, and fine tune the timing as they progress.
| Problem to solve | Intended behavior | Ideal use case | Reference |
|---|---|---|---|
|
As a User responsible for planning at a high level, I need to be able to plan work at the Epic level and assign it to a timebox, So that I can plan, prioritize and track efforts for the timebox. |
Can ship as individual iterations: - Users should be able to set a milestone at any epic level - The milestone set at the epic level should cascade down to descendant items (subepics, issues, tasks) - Users should be able to overwrite the inherited milestone on descendant records |
How does milestone, epic dates and iteration work together? The Product Manager creates a milestone for Q1, assigns that to the epic, then sets the dates on the epic to some 60 day period within Q1 to signal that's when they hope to address the feature within the quarter. Then as the epic is broken down into user stories, those issues receive the Q4 milestone/timebox and the development sprint is set using iterations. |
UX designs: #425088 (closed) docs to update: - Milestone - Manage Epics User personas: - Parker (Product Manager) - Delaney (Development Team Lead) |
Design iterations
Spike goals
This issue is created as a technical spike to explore requirements, complexity, and approaches for implementing Milestone functionality at the epic level. A spike is necessary in this case due to the cascading requirements with optional override; we'll want to ensure the approach for this requirements is implemented according to the work items architectural guidelines and groupproject management signs off on approach.
- Investigate the feasibility of adding Milestone functionality to the epic level.
- Explore the technical requirements for implementing the following features:
- Setting a milestone at any epic level
- Cascading the milestone set at the epic level down to descendant items (subepics, issues, tasks)
- Allowing users to overwrite the inherited milestone on descendant records
- Assess the impact on existing GitLab architecture and identify any potential challenges or limitations.
- Explore the complications arising from GitLab's organizational structure:
- Analyze how to handle the discrepancy between epics (available at the group level) and issues (available at the project level)
- Investigate the implications of milestones being available at both group and project levels
- Propose solutions for seamless integration of milestones across different levels of the GitLab hierarchy
- Determine the necessary backend and frontend changes required to implement this feature.
- Evaluate the performance implications of adding milestone functionality to epics, especially for large-scale projects with many epics and descendant items.
- Identify any dependencies or conflicts with existing GitLab features or ongoing development work.
- Outline potential testing strategies for ensuring the correct functionality of milestone assignment and inheritance.
- In addition to addressing the above spike goals, the output of this spike should include:
- A proposed implementation plan broken down into discrete epics and issues that:
- Represents the minimum viable change for each iteration
- Identifies clear dependencies between work items
- Indicates the required ordering of implementation
- Provides estimated level of effort for each component
- Highlights any required infrastructure or architectural changes that should be completed first
- Each proposed epic/issue should include:
- Clear acceptance criteria
- Technical implementation notes
- Potential risks or complications
- Testing considerations
- A proposed implementation plan broken down into discrete epics and issues that: