Implementing Scrum3 min read

Product Backlog Refinement: The Greatest Non-Event Event In Scrum

Product Backlog Refinement isn't a formal Scrum event — but skipping it is why most teams struggle. Finish it before Sprint Planning, not during.

Whether you’re just getting started or an experienced practitioner Implementing Scrum today, one of the greatest non-event events in Scrum is called “Product Backlog Refinement.”

Since it’s NOT a formal event in Scrum, I’ll refer to it here as a “session” we have together as a Scrum Team.

PSA: please retire the use of “Grooming the Product Backlog.” It’s no longer referred to that way in Scrum — it’s now called “Product Backlog Refinement,” and has been for a long time.

Huh. If Product Backlog Refinement is not an event in Scrum, then we don’t need to do it, do we, Mike?

Yep. You can skip it. Good luck with that.

One of the main reasons I get hired to help organizations Implementing Scrum is because the teams are not delivering (see darkscrum.com for more from my friend, colleague, and mentor Ron Jeffries, one of the original signatories of the Agile Manifesto). I’d be happy to help — contact me. Or you can save your organization some money and keep reading.

Where Is Refinement Mentioned In The Scrum Guide?

You can open a tab with the Interactive Scrum Guide free if that’s helpful. “Refine” is mentioned four times. Three worth noting:

But… Things Are Too Chaotic For Us

Spoiler alert: you are Implementing Scrum to help reduce the complexity in your organization. Keep it simple.

Reminder: you can do Product Backlog Refinement whenever it’s needed throughout the Sprint, or during “topic two” in Sprint Planning. Note: there is no longer any mention or recommendation that Product Backlog Refinement should take up to 10% of your Sprint time — that recommendation went away in the revision to the 2020 Scrum Guide from the 2017 version.

When Should We Do Product Backlog Refinement?

Here’s your free gold nugget:

Finish Product Backlog Refinement BEFORE you begin Sprint Planning.

While the Scrum Guide says you may do refinement during Sprint Planning, if that’s the first time you and your Scrum Team have seen the Product Backlog Items, you are screwed. You can (and should) still refine during Sprint Planning — but it shouldn’t be the first time you’ve seen these items.

Maybe you’ve been there:

Here’s your ticket out: do the Product Backlog Refinement prior to Sprint Planning. Finish it.

Trust me — you’ll be way more successful when Implementing Scrum in the real world (and save yourself a lot of money on consultants — though contact me if you want help getting this done without you making a career-limiting move; sometimes bosses like hearing it from “an outsider” even if you’ve been saying the same thing for years).

What Next?

Complete your Product Backlog Refinement before you head into Sprint Planning. You’ll notice three things happen:

  1. Sprint Planning will actually get DONE — you’ll finish on time with a clear Sprint Goal everyone is bought into.
  2. Since your items are refined, acceptance criteria and dependencies are identified before you get started. This is your secret to success when Implementing Scrum.
  3. Even though Product Backlog Refinement isn’t a formal event, spending time on it as a Scrum Team means fewer meetings and more done in less time.

This will also expose many other dysfunctional behaviors when Implementing Scrum — which really is the secret purpose of Scrum. The human element can make anything “easy and simple” even more complex. That’s why you’re using Scrum: the framework to get things done in real life.

Need some help with this? I can help you Focus and #deliver by improving your Product Backlog Refinement sessions together. I am a Strategic Consultant and Trainer — both private and public training available worldwide.

Contact me or connect with me on LinkedIn to discuss this more together.

Weekly, free, no fluff

Get one actionable Scrum idea a week.

Saturday morning emails on Implementing Scrum in the real world — the same cartoons and straight talk that built this site.

Subscribe — It's Free

Written by Michael Vizdos

35+ years working with teams around the world on Implementing Scrum. Found this useful? Feel free to share it with your team, or send feedback — I read all of it.