We upgraded to Silver because I liked some of the upcoming features for planning which would alleviate some of the problems we discussed in our teams, and I really pushed for that upgrade. Now, some of theme were post-poned to 12.9, and I can wait, but GitLab really feels like it's in a weird state.
For example, I can create boards that filter by milestone, but I can't create boards that filter by epic. I can't even add epics to milestones. So all in all, with the upcoming feature of assigning issues to multiple milestones, milestones seem like a much better way to group issues than epics.
In addition, with the upcoming feature "Show milestones in roadmap", I barely see any need for Epics, since they integrate so badly with the rest of the planning tools gitlab provides, and I wonder why epics are a thing at all (and why gitlab doesn't just drop epics in favor of a milestone-type called 'epic')
Another feature which I sorely miss, which are admittedly difficult to implement, are swimlanes/rows in issue boards. They would provide an entirely new dimension of possibilities. Relevant Epic in gitlab org: https://gitlab.com/groups/gitlab-org/-/epics/328
All in all, I love using Gitlab, but it also frustrates me greatly, since my main use is for its VCS and planning capabilites, and the latter is in a weird state, which leaves me with no choice but to wait.
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) 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) 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.
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.
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-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/) . 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). 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 ;)
I wish the full jira implementation wasn't only available in the most expensive plan. We would rather use gitlab but the cost would be more than double of what we pay for bit bucket.
sschueller, could you help me understand what you mean by "full jira implementation"? We are working to align our plan features to the right tiers (https://gitlab.com/groups/gitlab-org/-/epics/1887) and it'd be helpful to understand what specifically your are looking for.
For example, I can create boards that filter by milestone, but I can't create boards that filter by epic. I can't even add epics to milestones. So all in all, with the upcoming feature of assigning issues to multiple milestones, milestones seem like a much better way to group issues than epics.
In addition, with the upcoming feature "Show milestones in roadmap", I barely see any need for Epics, since they integrate so badly with the rest of the planning tools gitlab provides, and I wonder why epics are a thing at all (and why gitlab doesn't just drop epics in favor of a milestone-type called 'epic')
Another feature which I sorely miss, which are admittedly difficult to implement, are swimlanes/rows in issue boards. They would provide an entirely new dimension of possibilities. Relevant Epic in gitlab org: https://gitlab.com/groups/gitlab-org/-/epics/328
All in all, I love using Gitlab, but it also frustrates me greatly, since my main use is for its VCS and planning capabilites, and the latter is in a weird state, which leaves me with no choice but to wait.
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) 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) 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.
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.
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-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/) . 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). 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 ;)
Thanks in advance!