The importance of backlog refinement

Backlog refinement isnt a prescribed meeting, instead the Scrum Guide states:

The Scrum Team decides how and when refinement is done.

Perhaps thats why its not taken as seriously as the other scrum events, or worse, forgotten or ignored. Ive lost count of the number of project managers (or non-agile people) ask why are you spending time talking about the PBIs again?. Maybe its external pressure making teams drop refinement, but either way, its a big mistake.

The team Im currently working with have seen some real benefits from backlog refinement, so I thought Id get my thoughts down for the next time someone asks what are you doing?.

What is Backlog Refinement?

I wont go into depth as to what backlog grooming is as there are numerous guides out there. Instead Ill use the classic iceberg metaphor, i.e. the backlog has epics and the bottom, almost ready Product Backlog Items (PBIs or user stories) in the middle and some ready PBIs at the top:

Product Backlog Iceberg Metaphor
Product Backlog Iceberg Metaphor

Basically, the meeting is for the team to help the product owner move user stories up the Product Backlog. This raises awareness of the upcoming story and helps the Product Owner break the larger items down into user stories that the team feel could pull them into the next sprint.

As a rule (which isnt always possible for whatever reason), I like my teams to have a buffer of at least 2 sprints worth of Ready PBIs. Any less makes the next sprint planning problematic and any more I find priorities change and/or the team forget the details.

How long is Backlog Refinement?

Again, there isnt a hard and fast rule for how long this event should be. The Scrum Guide says (emphasis mine):

Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

As with everything scrum, its about finding a number that is just enough for your team to get the most amount of benefit and no more.

When should we do Backlog Refinement?

The current team Im working with have tried lots of things. Were currently have 2 regular events:

  1. An hour every week where the whole team sits down together and the Product Owner guides us through the backlog.
  2. Each team member is encouraged to spend at least 30 minutes each week going through the backlog on their own. (This started off as a meeting set in their calendars but we couldnt find a time that suited everyone, so the team are trusted to do this whenever its convenient).

As long as it gets done, and the team are seeing the benefits, I prefer to let the team decide.

The importance of backlog refinement

There are many more reasons to perform backlog refinement than Im going to list, but for me, the main benefits are:

  • Increased awareness of upcoming work. This leads to greater team buy-in and morale benefits
  • Smoother planning meetings (important if you have stakeholders attending)
  • Better understanding. The team can plan better, leading to less conflicts and an increased velocity
  • Fewer mid-sprint surprises like we didnt realise it was this complicated.

Ive read recently how Developers shouldnt measure twice, cut once and I think for the really excellent teams who know their code base inside out this may hold true. But for the rest of us, a little preparation can go a long long way.