4 ms·

A Plan Product Manager from GitLab here! Thanks for this feedback. Our vision is that Milestones are the best way to group issues over a spans of time, while

A Plan Product Manager from GitLab here! Thanks for this feedback. Our vision is that Milestones are the best way to group issues over a spans of time, while Epics work best for organizing related work that may span multiple milestones/longer development timelines. The Portfolio Management group is actively pushing to expand the functionalities of Epics across the board to better serve planning processes. Epics are young compared to our Issues and Milestones, and I agree we have many areas that need enhancement so the three can compliment each other. I also agree Epics should have the option to have milestones assigned to them (https://gitlab.com/groups/gitlab-org/-/epics/329 https://gitlab.com/groups/gitlab-org/-/epics/329) to better support planning over all. Any thoughts or additional feedback on that issue would be extremely helpful for the team as we map out the best MVC. Internally we have been discussing Swimlanes in boards (https://gitlab.com/groups/gitlab-org/-/epics/328 https://gitlab.com/groups/gitlab-org/-/epics/328) quite a bit and they would be a valuable add to our Boards. I'll share this thread with the other Plan team members and work to drive the conversation forward in that epic. Again, thank for this feedback, please continue to provide it so we can provide the right features to alleviate any frustration.

cuddlecake 7y ago
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 ;)

cuddlecake 7y ago

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 ;)