## Problem You can currently see the progress of epics in a roadmap and the likely date based on the schedule of associated issues, but this doesn't really surface that difference between the plan vs. reality. > This idea is very powerful. From the perspective of how people **plan** I believe they would benefit from putting in expected/idealized start/end dates for the epic objects. From the perspective of how people **develop** having that association that allows for the explicit enumeration of drift between the **planned** start/end and **actual developmental progress** start/end would be a significant and meaningful tool for those who wanted to look at the roadmap and elicit a sense of "how things are". [discussion from an epic](https://gitlab.com/groups/gitlab-org/-/epics/329#note_380681707) ## Proposal Allow an epic to have both fixed dates and inherited dates.  This idea was pulled from this comment (https://gitlab.com/groups/gitlab-org/-/epics/329#note_379486168) ## Acceptance - [ ] Allow an epic to be directly associated to 1 or more milestones - [ ] Allow an epic to also have a fixed date - [ ] If an epic has milestone(s), issues inherit the milestones. We need to figure out the UX around specifying which milestone an issue should have if there are more than 1 milestones associated to the epic. - [ ] Surface the fixed (planned) date on the roadmap and show the actual date (inherited from the milestone (probably iterations as well) - [ ] Provide visual indicators representing the variance/drift between planned vs. actual