Track scope change within milestone [3]
## FYI This Proposal Is Slightly Out of Date ## Problem Currently, milestones don't surface much meaningful information nor do they adequately tell the story of what happened throughout any given milestone. For example, currently there is no way to tell: - How much scope was added or removed through a milestone. - Which issues are carryover from a previous milestone. - Which issues did we miss? - What our capacity for a given milestone is. - Breakdown by teams or other organizational constructs. ## JTBD > When reviewing a milestone in progress, I need to quickly see progress against what we committed to, so that I can help make necessary course corrections and trade-offs to get back on track. > When reviewing a completed Milestone, I need to see if we completed what was planned -- and if not, why, so that we can have meaningful context to discuss process improvements. > When reviewing a milestone, I need to see a breakdown in progress across different forms such as by team, by project, by issue type, so that I can understand who is completed what and what kind of work is planned/done. ## Proposal - [ ] **Scope Change:** Add a burnup chart to Milestones (https://gitlab.com/gitlab-org/gitlab/-/issues/6903). - [ ] **Debt:** Represent carryover issues in burnup chart. - [ ] **Milestone Summary Report:** Rework area under charts and simplify issues list so it is easy to see which issues are open, completed, added to a milestone after it starts, or missed a milestone once it expires. - [ ] **Milestone Filtering:** Provide the ability to filter data within a milestone by label or project - [ ] **Quality of Life:** General UX cleanup: Too much whitespace, sidebar has some duplicate information, etc. ### Milestone Summary Report - [ ] Rework issue list columns into single issue list with the following filter options: `All`, `Open`, `In Progress`, `Closed` - [ ] Rework MR list columns into single MR list with the following filter options: `All`, `Work In Progress`, `Waiting for Merge`, `Rejected`, and `Merged` - [ ] Include MRs with `WIP:` in the `Work In Progress` list of MRs - [ ] Add infinite scroll pagination to all lists - [ ] Add the additional sort/filterability of issues based on the `New Issue States` in the section below. - [ ] Move sidebar data to a `Summary` tab - [ ] Rework Summary data to also display information around number of committed issues vs. completed - [ ] Rework Participants tab to display information similar to "contribution analytics" - [ ] For group level milestones, add some basic breakdowns on the stats/data displayed per project - [ ] Rework `Labels` tab to include more breakdowns along the line of Issues + MRs + All the various statuses - [ ] Explore having slightly different summary reports for when milestones are planning/open/in-progress and when they are expired/closed. Basically to highlight the needs to "give me a status update of where we're at" vs. "give me a summary overview of what happened during the milestone" #### New Issue States Specific To Milestones (and Sprints when they come...): - `Planned`: Issues that were assigned to the milestone when it was started. - `Carried Over`: issues moved into current milestone that were previously assigned to any other milestone - `Moved`: issues that were assigned to the current milestone but moved to a different milestone WHILE the current milestone is still active - `Missed`: issues that were not completed BEFORE the milestone expired or was closed) - `Unplanned`: Issues that were not `Planned` when the milestone started Additionally, if an issue was in a Milestone when it started, it should be treated as `Planned`. An issue can be `Planned` and `Missed` or `Planned` and `Carried Over` or `Planned` ## Rice | Item | Value | Narrative | | ------ | ------ | ------ | | Reach | `3.0` | This has been noted as a blocker to adopting GitLab's planning capabilities | | Impact | `3.0` | There is no way to tell if what was committed to was completed from an issue tracking standpoint. Companies won't use GitLab for planning until we provide basic reporting around this. | | Confidence | `100%` | This paint point is widely felt internally and externally. We've received support requests for this, and it is a widely adopted feature in some form or fashion in nearly every competing product. | | Effort | `3` | FE, BE, Designer @ 1 months = 3 | | ------ | ------ | ------ | | Score | **3** | (3 x 3 x 1) / 3 |
epic