This article by Martin Hinshelwood entitled—If your backlog is not refined, then you are doing it wrong; inspired me to write this article.
Here’s the LinkedIn post with some valuable commentary…
I wrote the first edition of my Scrum Product Ownership book in 2009, then a second edition in 2013, and a final/third edition in 2019. There was a period from ~2007 to 2020 where I spent a large portion of my time teaching and coaching in the agile product space.
One of the top three topics I explored over time was Backlog Refinement. I often coached team refinement sessions to explore, explain, and show good practices for emerging and maintaining a solid backlog.
Other product owners often attend to observe it as a fishbowl learning experience. While I’ve found no process or recipe for effective refinement, a set of patterns has proven useful.
Here’s a list of some of my previous writings around aspects of refining product backlogs—
Now, let’s discuss some additional aspects of backlog refinement.
First, the Scrum Guide
Honestly, I don’t care if refinement is in or out of the Scrum Guide. Nor do I care how it’s defined there—am I doing it “right” or “wrong.” Or if I’m doing Scrum by the book.
I’ve found that refinement is an activity and mindset central to effective team execution. That’s why it’s essential in Scrum, Kanban, and whatever you’re doing.
https://www.linkedin.com/pulse/story-promise-conversation-david-o-brien/
Second, It’s NOT a Meeting
I found this chart online quite a few years ago from Giora Morien, and it reminded me that refinement is not—
A meeting or event
A cyclical activity
Static
So, what is it?
It’s an ongoing, emergent workflow that leads to value delivery. It should happen continuously in the team via collaboration, conversations, discovery, and continuous clarification & understanding.
And, as the chart implies, we’re increasing our understanding (refinement) of each user story in the Backlog as it flows from refinement proper to sprint planning, to sprint execution – to delivery.
In other words, stories emerge from sprints as fully refined (understood, valued, designed) and delivered work.
As a supplement to this section, I’d like to share Tommy Norman’s article on Backlog Maturity Models, which adds something valuable here.
Third, It’s so much more than stories and backlogs!
And this is the most critical aspect to me as an agile coach and change agent. I’ve observed backlog refinement is a window into the organization and team cultures. By attending refinement sessions, I can see things like—
The willingness of the team to listen to all voices – activated deep democracy and respect.
The true DEI within the team is a microcosm of the organization.
The level of psychological safety that is present—healthy conflict, presence of 4 team toxins, challenging the status quo, experimentation, and failure.
Customer awareness or connection. How well does the team truly understand the “problems to solve” landscape?
Estimation dynamics often expose the technical understanding and skills of the entire team.
The power dynamics within and outside the team; speaking truth to power.
Open-mindedness to new ideas, approaches, and experiments.
Respect for agile approaches, roles, and boundaries.
Finally, I always get a great sense of the team's overall maturity concerning their context.
Wrapping Up
This article isn’t a reaction, positive or negative, to Martin’s. I think we both are bullish about backlog refinement. He perhaps more so because of the directive of the Scrum Guide and as a trainer.
Those things do not influence me. But I’m just as bullish, if not more so, by the collaborative power, delivery impact, and incredibly nuanced insights that can be gained by backlog refinement.
Net-net, I’d encourage everyone reading this to see backlog refinement as something vital to master for any agile team.
Stay agile my friends,
Bob.