Our project has an extensive backlog and as PM it is very helpful to keep the backlog up to date based on priority. We work in two-week sprints, but during a sprint we might drop out one issue in favor of another. Our way of work uses parts of Scrum and Agile. I want to make sure the issues we have in our backlog are ordered (combination of priority and severity) so whenever a sprint is cleared, a team member can pick up a new issue right away that is on top of the list without asking me if that’s best next thing on the list.
We used to work with labels and their priorities. This works, but it’s not ideal. Recently I’ve discovered the Manual sorting option and it was exactly what I needed. Before Gitlab, I worked on a project for a couple years that used JIRA. What I liked most about JIRA was the infinite scrolling list, able to create sections of tickets, and prepare before sprints. I use the Milestones in Gitlab to prepare for sprints now but it’s still less ideal than JIRA. I’m flexible and don’t expect to copy my JIRA way of work, backlog grooming, and sprint preparation onto Gitlab, but there are a couple things that
I’m wondering if I’m overseeing parts of Gitlab or if I have to do with the possibilities that I have in the situation we work in.
Once sorted by using the Manual option, I can’t drag and drop issues between pages. Is there a way to have all issues on one page for example? Currently I have to add a label to new issues, drag and drop those new issues above an issue which is higher on the list and then remove the label again. It doesn’t feel like the right way of doing and is quite cumbersome. When a new issue is created, I’d like to drag and it to the top of the list by myself (or as in JIRA -> right-click -> ‘Move to top of backlog’ -> drag to the right position from there). It is mentioned in the issue introducing the feature, but was left out of development I guess. Another follow up issue was created to introduce the ‘move to top / bottom’ button, but no updates for a couple months.
Are there any documents that explain the ‘ideal’ usage of issue lists in Gitlab? I have found similar documents about labels and how Gitlab is used internally, but not for issue lists per se.
Are there any blogs or articles about other PMs who do backlog grooming in Gitlab you’d recommend reading?
Ideally I’d just want one long list of all issues that I can divide into sections: top part is for next sprint, another section for issues that I’d like to have for the sprint after that, backlog with other issues below that I have prioritized.
Any input is welcome, thanks in advance!
P.s. Sorry, just realized this is the wrong subforum as this is not about configuring / installing Gitlab itself. Was redirected here from the Help-section.
Quick heads up on when you see no updates and want to add your point of view - feel free to comment on the comment making it a conversation. Asking doesn’t hurt, neither does constructive critizism. Often features are influenced and directed by new and fresh opinions.
Do you have a screenshot or URL? I cannot picture that in my head right now.
I think that really depends on the workflows and also amount of issues are being dealt with. As you may have seen with https://gitlab.com/gitlab-org/gitlab/-/issues - the issue list needs a different view for each team and group.
One thing which helps here are epics at the group level where the task issues are put into. The epic itself acts as a work item then. It does not have a milestone assignment yet, you can follow up in this issue.
For triaging and grooming, I’ve become a fan of the issue board. Especially because of the filter capabilities by labels, state, assignee, etc. - and you can hide columns not needed.
I like this one:
Our secure group discusses new ways currenty:
I’d loop @dplanella in here as we are evaluating this in the marketing team too
I have looked into Epics, but they’re not really applicable to our situation. Our team isn’t that big that Epics are necessary and I’m afraid it would only cause unnecessary administration and therefore confusion in the team. I can see it being helpful for multiple teams working on the same project / product, but in our case it’s one team working on one product together where all disciplines are involved at all times.
By using different columns, I was able to prioritize all the upcoming work and have everything on one page. When a new issue was created, it was added to the bottom of the backlog. Then, I could drag it up (or right-click ‘move to top of backlog’) and then move it upwards. By using different columns, named on the support page as ‘Selected for Development’, it was very clear what was prioritized, all on one page. An issue at the top would be up for next sprint, issue at the bottom of the page was either new (and not prioritized yet) or least important.
For example:
Next sprint
Issue 1
Issue 2
Upcoming
Issue 3
Issue 4
Backlog
Issue 5
Issue 6
As a product owner, it is not always clear how many issues we are able to plan for next sprint. That’s why it’s convenient to have a column such as ‘Upcoming’.
Using more issue boards looks like an okay alternative, it’s just that it seems to increase the amount of labels and milestones by a lot. I’ll look into it. Currently we only use an issue board for an active sprint with several lanes, which supports our work perfectly. I’m not sure how the flow would be from prioritizing everything on issue boards onto a separate issue board during a sprint planning to start a new sprint.
I’ll read up on the links you’ve provided, thanks a lot for all the input!
Often features are influenced and directed by new and fresh opinions.
