Product Backlog Refinement When Implementing Scrum

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

Whether you are 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. Meh.

This post digs a bit into what the five (well, if you don’t count the “container event of The Sprint) four Scrum Events, and when / why you should be using Product Backlog Refinement on a regular cadence when Implementing Scrum.

PSA: Please retire the use of “Grooming the Product Backlog” or “Product Backlog Grooming.” For so many reasons. It’s no longer referred to that in Scrum because… yeah. Because. Stop. Just Stop. It’s now called “Product Backlog Refinement” (has been referred to that for a long time now).

Focus. #deliver

Product Backlog Refinement is NOT an official Scrum Event (in the 2020 version of the Scrum Guide).

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 with people who are Implementing Scrum is because the teams are not delivering (see www.darkscrum.com for another rabbit hole of great information from my friend, colleague, and mentor Ron Jeffries — one of the original signatories of the Agile Manifesto for Software Development).

I’d be happy to help. Contact me and let’s talk about that (because I love consulting with companies and helping figure out stuff like this — it IS what I actually DO for a living and love working with people who love figuring all this stuff out together).

Or.

You can save you and your organization some bank and continue reading this post (smile).

First.

Where is Refinement Mentioned in the Scrum Guide?

Note: You can open a tab with the Interactive Scrum Guide free at www.InteractiveScrumGuide.com (this is the most current version of the Scrum Guide from Ken Schwaber and Jeff Sutherland) if that’s of interest.

When reading the Scrum Guide, “Refine” is referred to four times.

Let’s look at three of them:

1. Throughout the entire Sprint, the Product Backlog is refined as needed.

2. During Topic Two of Sprint Planning: Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

3. Product Backlog Refinement is finally “defined” in the Product Backlog Artifact within the Scrum Guide: Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items.

And, you can see the reference of “Refine” in the “People” footnote in the official Scrum Guide. Because I know you might be stressing over the reflection of the mention of the word “refine” four not three times. You’re welcome.

But… Things Are Too Chaotic For US

Spoiler Alert: You are Implementing Scrum to help you reduce the complexity in your organization.  

Keep It Simple.

REMINDER:

You can do Product Backlog Refinement whenever it’s needed throughout the Sprint.

You may do Product Backlog Refinement during “topic two” in Sprint Planning.

OK… So.

You can.

First, remember now there is NO MENTION or RECOMMENDATION that Product Backlog Refinement can take up to 10% of your total time in Sprint (this recommendation sadly went away in the revision to the 2020 Scrum Guide from the 2017 Scrum Guide).

When SHOULD We Do Product Backlog Refinement in Scrum?

Here is your free gold nugget here:

FINISH Product Backlog Refinement BEFORE you begin Sprint Planning.

While the Scrum Guide says (in topic two) that you may do refinement during Sprint Planning, IF you are just getting started Refining the Product Backlog at this point, you are screwed.

Really.

Yep, you can do this during the Sprint Planning (and should), but it should not be the first time you and your Scrum Team have seen the Product Backlog Items (aka User Stories or Jira Tickets or Trello Board Cards or Index Cards or Whatever).

Maybe you’ve been there (or are experiencing this today):

• You are in Sprint Planning (pulling the high priority ordered Product Backlog Items into the Sprint) and nobody has any context around the things you are pulling into the upcoming Sprint.

• Or, the Product Owner is winging it.

• Or, the Developers have never even seen this.

• Or, a HIPPO is in the room (Highest Paid Persons Opinion — could be your boss or some other outside stakeholder of your Scrum Team) and flinging around “new ideas” during Sprint Planning.

Get the picture?

Here is your ticket out of that hellish situation:

DO the Product Backlog Refinement prior to Sprint Planning.

FINISH IT.

Trust me. If you have not done this yet…

You’ll be WAY MORE successful when Implementing Scrum in the Real World (and save yourself a lot of money on consultants but hey, contact me to hire me to help you actually get this done without YOU making a career limiting moves — you can pay me to take the bullet for you (or actually your boss can pay me because sometimes bosses like hearing it from “an outsider” like me even if you’ve been saying the same damn thing for years).

What Next?

Easy.

Simple.

Complete your Product Backlog Refinement before you head into Sprint Planning.

You’ll notice three things happen:

1) Sprint Planning will actually get DONE because you’ve refined your Product Backlog Items ahead of the Sprint Planning Meeting Event. You know. You’ll actually finish Sprint Planning on time and with a clear idea of your Sprint Goal that everyone is bought into together!

2) Since your Product Backlog Items are refined, the acceptance criteria and all dependencies are identified before you get started. Right? Go back and read point #2 once again. Really. This is your secret to success when Implementing Scrum. You might need some help doing this (contact me).

3) Even though Product Backlog Refinement is not a formal event in the Scrum Framework, you’ll notice that if you spend time — as a Scrum Team — doing this, you will actually have less meetings and be able to get more done in less time (see focus_deliver.mvizdos.com for Thursday hints I publish every Thursday on LinkedIn!).

By the way, this will expose many other dysfunctional behaviors when Implementing Scrum (which really is the secret Purpose of Scrum).

The human element — people being people darn it — can make anything “easy and simple” even more complex.

That’s why you are using Scrum (the framework to get shit done in real life).

Need some help with this?

I can help you Focus and #deliver effectively by improving your Product Backlog Refinement events sessions together. Really.

I am a Strategic Consultant and Trainer (both private and public training is available worldwide).

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

One final thing…

Subscribe to my weekly Saturday morning emails about Implementing Scrum in the real world. And get an “every two week” check in from me too.

What could be better?

---