OMG. The boring Backlog refinement meeting. Not again! 🙄

Ditch that boring meeting! The closer look on some common anti-patterns of the backlog refinement based on my observations.

I have observed this pattern in several SCRUM teams. In all team member’s calendars, somewhere in the second half of the sprint, there is a big solid block. Usually, it’s a one or two-hour-long meeting called “Backlog refinement”, “Backlog grooming” or something like that.

And if you have a chance to join this meeting, within 20 minutes after it starts you can see team members occasionally peeping on their phone screens. And towards the end, only one or two members + product owner are actively participating in the meeting while the rest has more important things to do.

More honest team members will admit to you, that they just find the whole thing boooooring.

Why is that?

Because it’s not a meeting!

Well, at least it’s not supposed to be one in the first place. Backlog refinement is not a meeting, it’s an activity. Don’t believe me? Check The Scrum Guide.

Yes, it can be beneficial for some teams to run it in a meeting format, but chances are that if you recognise your team in the description above, it may not be your case.

Backlog refinement is an ongoing process. What should be the output of that process? :

“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.”
— The Scrum Guide

What level of detail is required? Well, that depends on the team. Here are some examples from my current team’s Team agreement:

• How do we know it’s done?
• Do we have everything we need to deliver this?
• Do we have a general idea on how to tackle this?
• Do we share understanding about the desired outcome?
• How long will it take to complete this?
• Can it be split to smaller chunk while still delivering value?

Refinement is not the estimation!

Have you noticed that I did not say anything about estimating PBIs or stories? Yes, the team should agree on how long will it take to complete the PBI, but that does not mean that some mandatory planning poker or similar technique should be employed.

Think about how do you work with the estimates? How do they influence your decisions? What level of precision do you really require? Are your needs genuine? Adapt your refinement and estimation techniques to meet those needs.

Refinement is not the place for low-level problem-solving!

This is tightly related to the estimations. Often the detailed low-level solution is discussed on refinement meetings to split the PBI into more detailed tasks.

This drags the discussions and makes the less technical team members lose focus since they can not work in such technical detail.

When is the granularity just about right? When the whole team agrees on the refinement that the PBI can be delivered in one sprint. And agrees on the planning how many more PBIs like that they can take into the sprint.

If you had refined the PBI to hourly tasks, you are probably in too much detail.

Ok, so when do we split the PBI to tasks then?

The right question is: “do you need to?”

Since the sprint is usually one or two weeks long, do you need to systematically track this day-to-day work or individual contributions to the code?

In my experience, most teams do not. It’s the high-level story/epic that is tracked in releases, interest managers and in the end, delivers the value to the end-user.

If you refine the PBI to the right level of detail (That question “Can it be split to smaller chunk while still delivering value?” does help here), you should be able to deliver it in a matter of days. How do you sync your work during this couple of days? You create a plan for the day on the morning daily (or stand-up), and you talk to each other during the day!

What to do with all this?

“The Scrum Team decides how and when refinement is done.”
— The Scrum Guide

Experiment! Find the sprint setup that best suits the needs of your team. Try things like (but definitely not limited to):

• have a bored tester on the first day of the sprint? Pair him with somebody to start the refinement process
• do backlog refinement in pairs or triads
• have only a sync meeting(s), where these smaller groups present the results

Every experiment, that gets you the desired outcome and makes the team engaged, could be worth trying 😉