Why Are Most Backlog Refinement Sessions Dreadful
The five elements you should avoid during your refinement sessions.
The five things you must avoid during your refinement sessions.
Many organizations claim to be agile; they believe they do Scrum. Yet, they make endless mistakes with the refinement sessions. A widespread misconception is to force the team to estimate pre-defined solutions. After each session, the team’s mood is low. They feel locked in a vicious circle because the mission is missing. Still, executives insist they are an agile company.
Does this scenario ring a bell for you? I’ve been in similar situations many times. The only certainty is frustration. Until collaboration is the focus, the Scrum Team has no chance of becoming a high-performing team. It’s time to change this awful scenario. Scrum teams should not accept misconceptions; you should fight against them.
If you want to build meaningful products, you cannot bow to anti-patterns.
Let me share with you some insights on what not to do during the refinement sessions. Hopefully, you can avoid these traps and lead teams in building delightful solutions.
Recently, I posted similar content to my YouTube channel. If you want to know more about the refinement session traps, I’d recommend you watch this video.
What Is the Backlog Refinement Session?
The Scrum Guide is not prescriptive on how to perform the refinement sessions. But it gives essential elements on what should be part of it. Let’s have a quick look at the Scrum Guide. In bold, you can read the most relevant details.
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Scrum Guide misses clarity on the expected outcome, in my opinion. For me, an excellent refinement session will result in:
Shared understanding among the team members: they know which problem to solve and why it’s worth solving it.
Ready to work on it: the team is prepared to solve the problem. They know how to move work with a meaningful solution.
How long should the refinement sessions last? It depends on the team’s size and product complexity. But in general, for a two weeks Sprint, between one and two hours session per Sprint is enough. Less than an hour is not enough to achieve the expected result, and more than two hours reduces the team’s productivity. You should find what works better for your scenario.
Now, let’s explore what the traps within the Backlog Refinement are.
1. Don’t Plan Solutions
It’s hard to believe, but many Scrum Teams focus on solutions to implement instead of solving problems. Although many product specialists have shouted, “First comes the problem; then the solution,” Scrum Teams keep falling in love with the solution while neglecting the problem.
“It’s not the customer’s job to solve their own problems. It’s your job to ask them the right questions.”
― Melissa Perri, Escaping the Build Trap: How Effective Product Management Creates Real Value
Suppose the goal of the refinement session is to clarify how to implement a solution. The team will most probably end up building something pointless for the users. Scrum Teams don’t need a solution to implement; they need a worthy problem to solve.
The Product Owner is responsible for finding a significant problem to work on. Not all problems are worth solving. When you find something that generates value for the end-user and the business, then you have found something relevant to focus on.
During the refinement sessions, you should aim to build a clear problem understanding. After the problem is clear for everyone, you can think of a solution, but never before.
2. Don’t Focus on the Estimates
Although you should size the items during the refinement, that’s just a means to an end, never the goal itself. No matter which technique you use to estimate your product backlog items, estimates are imprecise by nature. Don’t focus on the estimates; focus on understanding the different perspectives.
The most critical part of estimates is getting the team members to share their perspectives. Some team members might perceive a trivial problem, while others might think it’s tricky. When different opinions are shared, the team builds knowledge, which helps them progress because they are on the same page.
It’s never about getting estimates; it’s all about building a shared understanding.
It doesn’t matter if you work with story points, t-shirt size, #noestimates, or something else. What matters is how aligned on the problem the team members are.
Incorrect estimates should not be a source of concern. If a Scrum Team can consistently meet the Sprint Goal, then who cares if estimates are off? Accurate enough to meet the Sprint Goal means the estimates are good enough.
— Maarten Dalmijn, How Product Owners can stop developers from being a pain in the @## during refinement
3. Don’t Pressure Developers to Discuss What They Don’t Know
A common problem is pressuring the team to refine something just for the sake of refining. The Scrum Team won’t have all the answers for all the problems. Sometimes, they might need to stop and do more research into the item before refining it.
As the Product Owner, you should read the team's reactions to each item you want to refine. Once you realize the team is not ready for the discussion, you should agree on researching the problem to understand better how to solve it.
A research item is also known as a spike. It’s an agreement between the Product Owner and developers on how much time to invest in acquiring the required knowledge to move forward. But you should be careful not to create a spike for every doubt developers have.
High-performing Scrum Teams take risks, they are not afraid of the unknown; they are only afraid of not progressing.
4. Don’t Fall Into Endless Technical Discussions
If the Scrum Team has no psychological safety, they will do everything to avoid failures. Developers will ensure every technical aspect is covered before giving an estimate. The refinement lasts hours, and no items get estimated.
You shouldn’t blame developers for a wrong estimate. The refinement session is not the moment to discuss the solution; it’s the moment to understand the problem. If the discussion is focused on the implementation aspects, it’s a sign your team is missing the needed psychological safety. It’s a problem you must address.
The Scrum Team has a dedicated moment to discuss how to implement the solution: the Sprint Planning. After clarifying why the Sprint is important, crafting the Sprint Goal, and defining the Sprint items, the developers have the chance to break the items into the implementation components. Let’s have a look at the Scrum Guide. In bold, you can read the essential details.
Topic Three: How will the chosen work get done?
For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.
— The Scrum Guide, 2020
5. Don’t Bring Irrelevant Product Backlog Items
Some Product Owners love having an extensive Product Backlog. I used to do that; I kept creating more items to ensure the developers would always have something to do. Well, the amount of items in the Product Backlog doesn’t mean anything. What matters is focusing on what brings the most value for the end-users and the business.
When you refine many items upfront, you may still have the old waterfall mindset. You may follow a plan instead of learning from the users’ feedback and adapt your backlog to it. The secret is to focus on the Product Goal. We know the goal to pursue, but we have to accept we don’t know the complete path to get there. The Product Backlog should have the next steps towards the Product Goal, but not the entire route.
“In preparing for battle, I have always found that plans are useless but planning is indispensable. “
— Dwight D. Eisenhower
I used to bring many irrelevant items for the moment to the refinement sessions. Such items could become relevant in months, but not for the next Sprints. I wanted to have an accurate Product Backlog. Instead, we wasted our time. Whenever I suggested an item refined months ago for the Sprint, the developers would feel confused; they didn’t remember what it was about. Then, we had to refine it again.
Great refinements focus on the next step to get closer to the Product Goal. Think about what could the Scrum Team achieve next. Embrace learning; don’t focus on creating a precise plan.
“Winning products come from the deep understanding of the user’s needs combined with an equally deep understanding of what’s just now possible.”
― Marty Cagan, Inspired: How To Create Products Customers Love
Final Thoughts
The validity illusion holds us back from embracing learning. When we strive for security, we fail to adapt to the circumstances. We cannot become a robust Scrum Team if we focus on following a plan. To thrive, we have to follow what matters the most.
Without a value-driven mindset, Scrum Teams will be no more than cogs in a wheel.
Do you want to write for Serious Scrum or seriously discuss Scrum?