## Summary The current implementation of start and due date inheritance in GitLab epics fails to accurately reflect true project timelines due to gaps in how these dates are inherited from child issues. This can lead to misaligned expectations, inefficient project tracking, lack of adoption of tracking features and difficulty in planning across multiple iterations or milestones. By refining the inheritance logic, specifically allowing epics to inherit dates from any date based widget available on descendant children (milestones, iterations, start/due dates) we aim to provide more accurate, granular, and dynamic date tracking. This change will help users better understand the real start and end times of their projects, enabling more effective planning, resource allocation, and timely adjustments during the project lifecycle. ##### Current behavior _This [video](https://www.youtube.com/watch?v=q2x2vYIQcbQ&list=PL05JrBw4t0KpZSOi3eIYUs0Wuo7xtXpT7&index=9) walks through how the dates currently behave._ - A user must decide to either use inherited (automated) date ranges or fixed (manual) date ranges. - The date references from child records which are passed onto parent records are: - Epic: Start and Due dates (these child dates can be set to fixed or inherited for purposes of passing a date up to a parent) - Issue: assigned Milestone start and end date - Due date and iteration dates set on issues are not currently observed by the inheritance rules - When an epic is set to `inherited` and it doesn't have any children, or the children do not have any dates, the roadmap will render as if no records are found - When users are conducting high-level planning, they are typically using `fixed` dates. Once the feature enters work breakdown and child issues are created, the user has to remember to update the date criteria to use `inherited` to have an accurate picture of the delivery horizon. This is a painpoint highlighted by users. ## Proposal - [ ] Expand inheritance logic to consider dates from all descendant WITs (epics, issue, tasks) - [ ] Expand inheritance logic to consider milestone, iteration, start date and due date - [ ] When multiple date values are available from child records, the following priority should be given: - Where **iteration** and any other date value is available on a descent work item, use the iteration dates to determine the inherited epic start/end date - Where **milestone** and start/due is available on a descent work item (but not iteration), use the milestone dates to determine the inherited epic start/end date - When multiple iteration date ranges are present, the `start` should utilize the first chronological date and the `due` should utilize the last chronological date. Ex: iteration 1: March 15 - March 31, iteration 2: May 1 - May 14 / Epic date range = `March 15 - May 14` ## Reference - **[WIP - Design: Work item start/due date inheritance v2](https://gitlab.com/gitlab-org/gitlab/-/issues/389446).** Design and goals for inheriting start and due dates in work items and epics, and the issues with the current model. - **[View fixed vs inherited start and due dates of epics on roadmap](https://gitlab.com/gitlab-org/gitlab/-/issues/7076).** Users want to see exact start and end dates for epics without having to click through each one, indicating the current system's lack of clarity. - **[Discussion about milestone on epic](https://gitlab.com/groups/gitlab-org/-/epics/329#note_379486168)** <details><summary>Use case examples for testing</summary> | Ref|Scenario / Use Case|Example Dates|Epic:Start Date | Epic:Due Date| |--- |--- |--- |--- |--- | | 1|All dates present on children: all dates aligned within the larger context - happy path <br><br> _User story set to iteration within the milestone assigned to parent feature. Dev sets start and due date which falls within the iteration date range._ |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**: Mar 15 - Mar 31 <br> **Start**: Mar 18 <br> **Due**: Mar 25 | Mar 18| Mar 25 | |2 |All dates present on children: start and end dates fall outside iteration range <br><br> _User story set to iteration within the milestone assigned to parent feature. Dev sets start within the iteration but expects to finish after iteration completes._ |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**: Mar 15 - Mar 31 <br> **Start**: Mar 10 <br> **Due**: Apr 5|Mar 10 |Apr 5 | | 3|All dates present on children: start and end dates fall outside iteration range <br><br> _User story set to iteration within the milestone assigned to parent feature. Dev sets start prior to start of the iteration but expects to finish after iteration completes._ |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**: Feb 1 - Feb 14 <br> **Start**: Jan 15 <br> **Due**: May 15|Jan 15 | May 15| | 4|All dates present on children: end date falls outside iteration range <br><br> _Iteration starts prior to milestone, completes within the milestone range. Dev sets start within the iteration but expects to finish after iteration completes._ |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**: Jan 20 - Feb 05 <br> **Start**: Jan 25 <br> **Due**: Feb 25 |Jan 25 |Feb 25 | |5 |All dates present on children: scenario 5 |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**: Apr 20 - May 05 <br> **Start**: Apr 25 <br> **Due**: May 1 |Apr 25 | May 1 | |6 | |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**: Mar 15 - Mar 31 <br> **Due**: Mar 1 | | | |7 | |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**: Mar 15 - Mar 31 <br> **Due**: Mar 18 | | | |8 | |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**: Mar 15 - Mar 31 <br> **Due**: May 1 | | | | 9| |**Milestone**:Feb 1 - Apr 30 <br> **Iteration**:Mar 15 - Mar 31 <br> **Start**: Mar 1 | | | | 10| |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**:Mar 15 - Mar 31 <br> **Start**: Mar 18 | | | | 11| |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**:Mar 15 - Mar 31 <br> **Start**: Apr 1 | | | | 12| |**Milestone**:Feb 1 - Apr 30 <br> **Iteration**: Mar 15 - Mar 31 | | | | 13| |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**:Mar 1 - Mar 15 | | | | 14| |**Milestone**: Feb 1 - Apr 30 <br> **Iteration**:Mar 25 - Apr 11 | | | | 15| |**Milestone**:Feb 1 - Apr 30 <br> **Start**:Jan 15 <br> **Due**: Feb 15| | | |16 | |**Milestone**:Feb 1 - Apr 30 <br> **Start**:Apr 15 <br> **Due**: May 15 | | | | 17| |**Milestone**:Feb 1 - Apr 30 <br> **Start**:Mar 1 <br> **Due**:Mar 31 | | | |18 | |**Milestone**: Feb 1 - Apr 30 <br> **Due**: Mar 1| || |19 | |**Milestone**: Feb 1 - Apr 30 <br> **Due**: Jan 15| || | 20| |**Milestone**: Feb 1 - Apr 30 <br> **Due**: May 15| || | 21| |**Milestone**: Feb 1 - Apr 30 <br> **Start**: Mar 1 | || |22 | |**Milestone**: Feb 1 - Apr 30 <br> **Start**: May 15| || |23 | |**Milestone**: Feb 1 - Apr 30 <br> **Start**: Jan 15 | || |24 | |**Iteration**: Feb 1 - Apr 30 <br> **Start**: Mar 1 | || |25 | |**Iteration**: Feb 1 - Apr 30 <br> **Start**: May 15| || | 26| |**Iteration**: Feb 1 - Apr 30 <br> **Start**: Jan 15 | || |27 | |**Iteration**: Feb 1 - Apr 30 <br> **Due**: Mar 1| || | 28| |**Iteration**: Feb 1 - Apr 30 <br> **Due**: Jan 15| || | 29| |**Iteration**: Feb 1 - Apr 30 <br> **Due**: May 15| || </details> <details><summary>Archived description content</summary> ### Current ```mermaid graph TD Date_Range["Oct 1 - Oct 31"] --> Milestone Milestone --> Child_A Child_A --> Parent Child_B --> Parent Child_C --> Parent Date_Range2["Sep 15 - Sep 30"] --> Iteration_A Iteration_A --> Child_A Date_Range4["Jan 1 - Jan 15"] --> Iteration_B Iteration_B --> Child_B Due_DateA["Dec 31"] --> Due_Date Due_Date --> Child_C Date_Range3["Inherited:<br> Oct 1 - Dec 31"] --> Parent ``` ### Proposed ```mermaid graph TD Date_Range["Oct 1 - Oct 31"] --> Milestone Milestone --> Child_A Child_A --> Parent Child_B --> Parent Child_C --> Parent Date_Range2["Sep 15 - Sep 30"] --> Iteration_A Iteration_A --> Child_A Date_Range4["Jan 1 - Jan 15"] --> Iteration_B Iteration_B --> Child_B Due_DateA["Dec 31"] --> Due_Date Due_Date --> Child_C Date_Range3["Planned: Sept 1 - Dec 15 <br> Rollup: Sept 15 - Jan 15"] --> Parent ``` ## MVC 1 ### Proposal - A start and end date can be assigned to a work item ### Acceptance Criteria - [x] A start and end date can be added to a work item. - [x] The start and end date can be updated at any point in time. - [x] Dates update in real time. - [x] Redis Counter ### Redis Counter - **name:** `users_updating_work_item_dates` - **redis_slot:** `users` - **include in the following aggregation counters:** - [x] `xmau_plan` - [x] `xmau_project_management` - [ ] `xmau_product_planning` - [ ] `xmau_certify` - [x] `users_work_items` ## MVC 2 - DRAFT ### Proposal 1. If a work item is associated with a Milestone or Iteration, the `Start` and `End` dates will automatically be set to the Milestone or Iteration Start and End dates. 1. If a `Start` and `End` dates are set and are outside of the Milestone or Iteration ranges, the user will receive a warning. 1. **Question**: Should we allow work items to have `planned start/end` dates that are outside of the ranges for the milestone/iteration? Right now, I am proposing a warning vs a hard stop. 1. Feedback from [customer](https://gitlab.my.salesforce.com/00161000015MAsE) is that milestone and start/end are an either/or. 1. **Question**: Do users perceive the planned start and end date as related to the milestone/iteration? Should work items have a `Planned Start`/`Planned End` and `Milestone`/`Iteration`? 1. Feedback from [customer](https://gitlab.my.salesforce.com/00161000015MAsE) is that milestone and start/end are an either/or. ## MVC 3 - DRAFT Rollups 1. If a `Start` and `End` dates are set and are outside of the work item's parent ranges, the user will receive a warning. 1. A work item will be able to see a rollup of it's children work items `Start` and `End` dates. The `Planned Start` date will be the earliest `Start` from the children's work items. The `Planned End` date will be the latest `End` from the children's work items. 1. **Question**: Should we allow child work items to have `start/end dates` that are outside of the ranges for the parent? Right now, I am proposing a warning vs a hard stop. 1. Validation from [customer](https://gitlab.my.salesforce.com/00161000015MAsE) is this is the right direction. Show a warning in the roadmap and other views. 1. **Question**: How do blocking/blocked by relationships factor into planned dates? ## MVC 4 - DRAFT Milestones/Iterations 1. If a Milestone or Iteration is set on a parent item, that will be visible in child work items and can be optionally applied. 1. We will display a warning if a Milestone or Iteration is set on a child item that is outside of the date ranges for the Milestone or Iteration's parent. 1. **Question**: Should we allow child work items to have Milestones/Iterations that are outside of the date ranges in its parent? Right now, I am proposing a warning vs a hard stop. 1. Validation from [customer](https://gitlab.my.salesforce.com/00161000015MAsE) is this is the right direction. Don't set the value for the milestone on behalf of a team. ## MVC 5 - DRAFT ### Proposal `Actual Start` and `Actual End` dates will be system generated and reflect when work happened. 1. When An In Progress status is available, the `Actual Start` date will be updated when a work item is first set to In Progress. 1. The `Actual End` date will be updated to that date when the work item is Closed. 1. The `Actual Start` and `Actual End` dates for parent work items will be inferred from child work items by taking the earliest `Actual Start` and `Actual End` from its child work items. 1. If a work item has both inferred `Actual Start` and `Actual End` (dates derived by its children `Actual Start` and `Actual End`) and set on it(when it was set to In Progress or Closed), the inferred dates will be used. 1. **Question**: Should the marker for when `Actual Start` and `Actual Start` get set be configurable? 1. **Question**: Is this concept valuable to customers? Would it be better to use `Actual` dates differently? </details> ____ <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->