Backlog refinement is an activity carried out by Scrum teams on the Product Backlog, described in the Scrum Guide as:
“… an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised.” ~ Scrum Guide
Backlog refinement (or “grooming” as it commonly gets called) is, from a purely Scrum perspective, about ensuring the Product Backlog — a list of items representing our current thinking about what we need to do to build the product — is appropriately ordered, items are appropriately sized and with the appropriate level of detail.
But if we step back and consider how we should actually accomplish this in the arena of a value-creation pursuit such as product development — particularly considering Scrum is all about maximising the value of the “product” we are developing — backlog refinement ought to involve:
Remember, if we’re using Scrum as intended, we’re looking to do things which we believe will create the highest possible value for the product in each Sprint, and we can only know what’s possible — not to mention what value and highest possible value even mean in our ever-changing context — if we explore all the possibilities, and do so frequently.
Contrary to this, many teams treat backlog refinement as purely about putting acceptance criteria and/or estimates on the current PBI’s, i.e. with a “next Sprint” lens rather than an “entire backlog” lens (the latter is required in order to be iterative and not only incremental).
It’s also worth mentioning that backlog refinement used to be listed as a formal “Event” in Scrum, but was “relegated” to a core activity a few years ago. Hopefully you can see from what I’ve said so far on this topic, this was actually an important change — backlog refinement is the continuous exploration of value opportunities, and expression of consequential intent through an ordered product backlog. As such, it cannot be confined to a single time-boxed meeting in each Sprint.
As a minimum, always be sure to read, understand and apply the Scrum Guide if you are doing Scrum — the working patterns in there are only in the framework in the first place because they have been demonstrated time and again to be effective guardrails for many teams across the world to be very successful at generating maximum value in the shortest period of time.
If you enjoyed this post, you might like to subscribe to my weekly newsletter. Each week you will receive my latest thoughts and activities in the agile product development arena, along with early and exclusive snippets of my upcoming book 20 Software Estimation Dysfunctions and How to Avoid Them.