We often have extra time at the end of triage each week, and we have stated many times that “issues go to the backlog to die”. Well, why don’t we use some of that extra time (only if there is time, and not before reviewing issues on a release, if requested) to review some of those stale issues?
I’ve created a query in redmine to list stale issues (non-closed, created > 1 year ago, last updated > 1 month ago, including non-backlog issues). There are about 1000 in that list, but I have a feeling many of them can be closed without much discussion. We can also use this time to determine issues we want on team-specific backlogs, if any.
If we don’t come up with some strategy to deal with and plan to fix the ‘stale’ or backlogged issues, the list will just continue to grow. I think this could at least be a start; I’m not realistically expecting to get the list to zero, but I do think it could help our sub-teams plan work for more redmine issues.
We definitely need to address the indefinitely growing backlog. I find that the triage sessions usually don’t leave us too much time left over - especially when we are reviewing releases and such. In all honesty I wouldn’t feel very motivated to jump into a backlog grooming after a 45 minute ordinary triage for example. Maybe that’s just me!
Piggybacking on Eric’s suggestion: I’d be more of a fan of a dedicated backlog grooming session for that specific purpose - once a month or whatever we want to do. It’s something I’ve done in the past and it worked pretty well for working through the buildup.
I’d be down for a regularly scheduled backlog grooming session. We may even be able to do some of it in parallel, rather than triage style of one person screen sharing while others look on, by each taking a category or status and speaking up in the meeting when there are questions. We could also start by looking at issues that are assigned to each of us, if any. I don’t know about you, but I kind of dread going through 1000 issues one by one like we do in triage.
