A quick guide to Backlog Refinement
Thanks for following my blog! 😊 Please support my work further by reading this and other articles from my my company blog.
If you have any questions about anything in this article, or need a hand with your lean/agile product development or agile transformation endeavours, please reach out directly to me or my company Hypothesis.
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:
- Conducting customer and user research and design activities to identify new market opportunities (options), and how to better exploit existing value streams
- Describing/ordering these options for value-creation as PBI’s (Product Backlog Items), based on our findings from research and design
- Paying extra attention to the most immediately impactful opportunities — i.e. the items we put at the top — and ensuring we have enough confidence and detail to start development of those items
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.
