7 ms·

Hi, thanks for the reply. As I mentioned, I use milestones the way that you envision epics right now. I group all issues that somehow belong together, for whic

Hi, thanks for the reply. As I mentioned, I use milestones the way that you envision epics right now. I group all issues that somehow belong together, for which I want to track progress (and burndown/up over time) in a milestone. The milestone detail view is perfect for this. It has a description, a timeline, start and end date, unstarted, ongoing and finished issues, etc. All they lack to be even more "epic-ish-ly" for me would be a comment thread (as issues and epics have). Essentially, we use milestones as a well-integrade epic-surrogate, while compromising our ability to perfectly track progress on the current sprint (which will probably be resolved soon, with multiple milestone types and multi-assignment). Also, a way to drag issues into a sprint milestone would be great. (Unless the issue list reflects the priority sorting that is established in the open column of unfiltered boards by dragging issues up and down, then a multi-edit would suffice). For disclosure, we are a team of ~10 developers working mainly on a single project within a single group. So, switching between the 'group' and 'project' views is not something we do often, since we plan mainly for the project that we work on. So, we barely have visibility of the 'Epics' view in the first place (in fact, when we upgraded to Silver, I didn't even know where to find Epics). I think that I'm also lacking something that screams "CLICK ME TO GET TO THE GROUP THIS PROJECT YOU ARE VIEWING BELONGS TO" other than the breadcrumbs. At least I am _always_ looking at the sidebar first, then using the top navbar (completely ignoring the breadcrumbs, every time) Anyway, integrating epics with milestones seems difficult. I think a first great step would be to be able to assign a milestone to an epic (i.e. epics belonging to milestones). That could have two immediate effects: The milestone inherits due and start time from epics, and the epics and sub-epics automatically inherit assignment to that milestone. This presumes my view that milestones progress when epics belonging to that milestone progress, and epics progress when sub-epics or issues belonging to that epic progress. This, combined with the ability to have boards for epics, as I have boards for milestones right now, would probably suffice for me to feel comfortable with using epics at all. But, I doubt that, even if the aforementioned is implemented, I will get to see the features since I assume they will have Gold-level pressure on infrastructure (they are similar to some of the features that multi-level epics currently implement, and those are gold-level, too). Since I'm already in the flow: A really funky feature would be boards that are scoped to Milestones. I.e. not boards filtered by Milestones, but boards that belong to a milestone and not to the project. Currently, I have a board for every milestone (our pseudo epics) with our column workflows, and the ritual of creating that could be avoided and made predictable. In any case, I'm waiting patiently, and observing the gitlab-org epics.

gabeweaver 7y ago
Hi...I’m another Plan PM and would love to jump in. Thanks for being patient…and even more so for contributing your perspective to help make GitLab better for the wider community. I agree with you that we need to do a lot of improvement around the UX of Group/Project navigation — especially when something is in one and not the other. Here’s a bit of additional background context on Epics... We noticed that a lot of folks have been trying to use Milestones for Epics. I think a main reason for this was due to the fact that up until yesterday when 12.8 was released, Epics were restricted to Ultimate (https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-released/#single-level-epics-now-available-in-premium https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-rel...). We made this change because we believe Epics and Milestones serve two distinct purposes and are applicable to Directors as the buyer — and even arguably Managers — within our pricing model (https://about.gitlab.com/handbook/ceo/pricing/ https://about.gitlab.com/handbook/ceo/pricing/) . The goal of Milestones is to group issues by time horizon, whereas an Epic is used to group issues by subject matter. This also typically maps to different key personas within an org and how they measure progress. Within GitLab, Issues are the key object that links Milestones to Epics. By looking at an Epic’s issues, we dynamically derive delivery dates of an Epic based on when the underlying children issues have been scheduled for implementation. We designed it this way so delivery teams didn’t have to constantly answer the question “when is this coming and are we on track,” instead surfacing that information automatically on the roadmap to keep stakeholders across the business updated. We also did this because we believe the timeline should reflect the reality of the teams that are responsible for delivering and not a forced, untenable schedule that will leave teams burnt out. While this is the inverse approach you suggested with Milestones inheriting due dates from Epics, we think this will ultimately result in a healthier relationship / scope trade-off discussions between delivery teams and their stakeholders. As for surfacing Epics within Boards, we plan to tackle that with via horizontal swimlanes (https://gitlab.com/groups/gitlab-org/-/epics/328 https://gitlab.com/groups/gitlab-org/-/epics/328). Additionally, we aren’t planning on making Boards within Milestones, but we are planning on extending Boards to make grooming, managing a sprint, and doing capacity planning a much more delightful experience. I really appreciate your input and would love for you to jump into some of these issues or open new ones in gitlab-org with your feature requests! Lastly, I understand what you mean when you say things feel a bit "weird". Iterating quickly doesn't always produce the most polished experience while big features are being developed, but it does yield the best long term outcomes as a result of more frequent and timely feedback like this ;)

gabeweaver 7y ago

Hi...I’m another Plan PM and would love to jump in. Thanks for being patient…and even more so for contributing your perspective to help make GitLab better for the wider community. I agree with you that we need to do a lot of improvement around the UX of Group/Project navigation — especially when something is in one and not the other. Here’s a bit of additional background context on Epics... We noticed that a lot of folks have been trying to use Milestones for Epics. I think a main reason for this was due to the fact that up until yesterday when 12.8 was released, Epics were restricted to Ultimate (https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-released/#single-level-epics-now-available-in-premium https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-rel...). We made this change because we believe Epics and Milestones serve two distinct purposes and are applicable to Directors as the buyer — and even arguably Managers — within our pricing model (https://about.gitlab.com/handbook/ceo/pricing/ https://about.gitlab.com/handbook/ceo/pricing/) . The goal of Milestones is to group issues by time horizon, whereas an Epic is used to group issues by subject matter. This also typically maps to different key personas within an org and how they measure progress. Within GitLab, Issues are the key object that links Milestones to Epics. By looking at an Epic’s issues, we dynamically derive delivery dates of an Epic based on when the underlying children issues have been scheduled for implementation. We designed it this way so delivery teams didn’t have to constantly answer the question “when is this coming and are we on track,” instead surfacing that information automatically on the roadmap to keep stakeholders across the business updated. We also did this because we believe the timeline should reflect the reality of the teams that are responsible for delivering and not a forced, untenable schedule that will leave teams burnt out. While this is the inverse approach you suggested with Milestones inheriting due dates from Epics, we think this will ultimately result in a healthier relationship / scope trade-off discussions between delivery teams and their stakeholders. As for surfacing Epics within Boards, we plan to tackle that with via horizontal swimlanes (https://gitlab.com/groups/gitlab-org/-/epics/328 https://gitlab.com/groups/gitlab-org/-/epics/328). Additionally, we aren’t planning on making Boards within Milestones, but we are planning on extending Boards to make grooming, managing a sprint, and doing capacity planning a much more delightful experience. I really appreciate your input and would love for you to jump into some of these issues or open new ones in gitlab-org with your feature requests! Lastly, I understand what you mean when you say things feel a bit "weird". Iterating quickly doesn't always produce the most polished experience while big features are being developed, but it does yield the best long term outcomes as a result of more frequent and timely feedback like this ;)