5 Things I’ve Learned Running Backlog Grooming Meetings

If you’re not familiar with the idea of backlog grooming start here.

I’ve been running scrum meetings and grooming sessions for years. It’s always tricky to tell when you need to add more detail to a task versus when it’s ready for work. I thought I would share a few of my thoughts on deciding when a task has enough detail to be worked on

1. The word count of a task is a good early indicator of how complete a description is

This task is real short

Upgrade systems to java 11

This task is much longer

Research spike: Investigate the impact of a language migration. We will need to find java 8 specific language features in use, and assess feature of java 11 that are not backwards compatible.

Acceptance criteria: Documentation on probably java 11 issues, follow up tasks for the actual migration work

The first version needs to be groomed more (i.e. more detail added so it can be picked up by an engineer) while the second one has enough detail and acceptance criteria for someone to get started.

2. Voicing your own confusion will get others talking

If you’re confused as the scrum master it’s likely someone else on the call is confused as well. Going back to our java 11 upgrade example if you found the first 5 word description in a task you should voice your own confusion. Statements like, “I don’t think I’ve got a good sense of this — what would this take to complete?” Can help kick start the conversation to figure out the task.

It will both allow other people who are confused to say so, and encourage the person who created the task to start explaining themselves. It’s best if these statements are non-confrontational. Your goal should be to create a question someone else wants to answer, rather than accuse someone of not giving enough detail up front.

3. Standardize on basic fields that should be filled out in the tasks

We encourage everyone creating a task to fill in a “description” section with some background on what needs to happen, and an “acceptance criteria” section that says when the task is completely done.

There are other common sections we see like “problem statement” and “references” that can be helpful for giving context for what work needs to happen.

Standardizing these sections makes it easier for everyone to know what you expect when you say, “Can anyone help me fill in acceptance criteria?” Or if you just start editing and type “acceptance criteria” it will get people thinking of what you want.

4. The number of links is a good early indicator of how complete a task is

If you open a task and immediately notice a number of links that’s a good early indicator that the task is ready to point. Even if the word count of the task description is low links are a good sign that enough context has been pulled together for an engineer to work.

5. If you have as many different estimates as engineers, something is missing from the task

If you’re not familiar with pointing poker read this article. If you’re grooming tasks and you go to point it, and you have as many different estimates as you have engineers (or close to it) then you’ve missed a detail on the task.

Start with the highest and lowest vote and ask both of them why they voted the way they did (if you’re one of these voice your opinion in a couple short sentences) and wait for one of them to start persuading the group up or down on the estimate.