Backlog refinement process for Static Analysis

Problem to solve

We're currently trying to do backlog grooming as a background process, which engineers do every single week. The problem is we're all busy (too busy?), and backlog grooming is admittedly the first job that gets punted when we become stressed. This isn't sustainable, and is causing us to become reckless about issues that are being accepted into releases.

If issues are not groomed, why are they being accepted into releases?

To be blunt, because we repeatedly run out of work for folks which is groomed. A byproduct of the GitLab cadence is we're pushed/forced to commit to new work on at least a monthly cadence. This is a big batch size of work to commit to, and a lot of processes are hung off of it. Most notably, the release kick-off videos and release posts.

What are we trying to do in this issue?

Let's brainstorm about ways in which we in Static Analysis can do better around backlog grooming. At the risk of turning this into a retrospective issue, commentary on the following would be most appreciated.

1. What's the hardest part about grooming?
2. How can we make grooming easier?
3. How can we keep the flow of issues being groomed consistent throughout a monthly release cadence?
4. Are there ways by which we can reduce the batch size of work being groomed?

Proposal

• Start an MR against the handbook to improve documentation about how to move past the planning gates.
• Change guidance on how much to groom so it’s set by weight rather than number of issues. Target: weight of 6 per week.
• Put backlog grooming office hours on the schedule each week. Schedule for Thursdays.
• Finalize a long-running MR I have to update weights we set in the handbook. Biggest change will be reference issues for each weight rather than an estimated duration of effort.