Ask HN: Have you ever enjoyed a backlog grooming meeting?

[aprinsen]

This type of thing may go by different names, but I'm talking about the sort of regular meeting where engineers and perhaps product folks discuss a list of possible work items individually to clarify, prioritize, and estimate effort.

I've often found it hard to keep these meetings engaging, so I'm curious if folks have tips for running them. What has worked for your teams? What should be avoided?

[Aromasin]

I do hardware application design-in at [insert NASDAQ silicon company] and we have these sort of reviews weekly where we go over customer tickets that we're struggling with, and people pitch in to give advice/contacts/morale support.

Some weeks it really drags. I think that's inevitable. The ones it doesn't though, for me at least, are when the engineering leads make an effort to give people launch pads to start a conversation on the issue. By that I mean, they ask questions - often intentionally stupid ones - to get people thinking. Doesn't have to be a Shakespearean monologue, just a couple of basic suggestions out loud, that spark thinking in the rest of the call. The answer is probably there, it just needs to be fished out of someone's head. If you ask "does anyone have any suggestions" then the call is silent, but give a wrong answer and all of a sudden everyone is keen to jump in and correct. Its a surprisingly effective method.

[blablabla123]

Grooming tickets that have already been started and identified to actually need grooming as well as keeping number of meetings to an absolute minimum. This way at least one person is fully engaged and there's no meeting fatigue...

(But I know the problem, extended grooming meetings can be the most draining of all...)

[splittingTimes]

The most engaged discussions happened when we had a huge wall that the team (devs+PO) had filled over time with many post-its to concretize the user story map. We would sit together on couch and look at the story map and update it together, noting where we find new unknown requirements, where we did not finish a feature, where bugs were found, etcs.

In terms of estimation we ran fast-estinmation games. Time boxed to 15min we meet after lunch break and do the following:

We have post-its on the wall indicating columns for the story points. We have a stack of print outs of the tickets to estimate. (Sometimes we spend 10min in the beginning and read all tickets) The game goes like this:

1. First dev picks a ticket, reads out the short summary of the issue and files it under one SP column.

2. Next dev can either pick a new ticket of the stack and place it on the wall OR can move an existing ticket into another column.

3. Rinse repeat until the stack is empty and no more tickets are moved between the columns.

If a ticket has been moved more than three times it gets flagged and set a side to be discussed in more detail in a separate session.

This is really a fast way to get rough estimate (which is really all you need) and it keeps every dev active.

AVOID meetings where everybody sits around the table and the scrum master has an excel sheet or JIRA open on the screen and tries to fill out fields with the estimates.

AVOID discussions if a ticket is a 2 or 3 or 5 or 8. Pick one and move on. Do discuss when one is 2 and the other is 8.

AVOID having long meetings where you do all things together (prio, clarify, estimate). Instead do a fast estimation first, even with some details missing, but with a rough understanding what is wanted in the tickets. With these estimates the PO can do the Prio (business value vs effort). Then you know what to work on next. For those tickets do the clarification and technical detail discussions inside small groups of the dev team.

AVOID forcing every team member into these meetings. Not all have to be present to do a fast estimation session or any other SCRUM artifact. Some people feel more owner ship for a feature/product other just want to know which tickets they can crush next. I always tell my team, if anyone feels

- he cannot contribute to a meeting,

- the agenda is not relevant/interesting for her/his current work

- he/her trusts the group to come to a sensible decision without her input.

- other urgent work needs to be done

- is in a state of coding flow

Then don't join the meeting. It is also totally fine to leave in the middle of a meeting when you do not get sometime out of it. Encourage your team to do that. It reduces frustrations a lot.