Product Backlog Refinement Hell: 3 Problems and Solutions

Bad Sprint Planning almost always traces back to the same place: poor Product Backlog Refinement. I’ve said this in workshops for years. The response I get most often? ‘Our refinement drags on forever’ or ‘1hr in refinement feels like 3hrs in real time.’ So here’s what actually helps.

Hint: there is a whole class of challenges around meeting hygiene and decision-making that I won’t cover here. We already have articles on why group decision-making techniques matter and how team friction inspires working agreements.

What is Product Backlog Refinement?

At the simplest level, Product Backlog Refinement is the process of preparing the Product Backlog for the next Sprint. If the previous Sprint delivered six or seven User Stories, the Product Backlog now has six or seven empty slots. Refinement is replenishing the queue.

For years, it was called Backlog Grooming, but that term was dropped over a decade ago. Grooming always seemed odd to me. When we groom a pet that has been out of the house, we’re cleaning it up. Why would we do that to a backlog? Refinement means to sharpen or improve; that seems like a better fit.

Refinement includes:

• Reprioritizing items in the Product Backlog
• Breaking down large items into smaller pieces
• Clarifying
• Adding and, more importantly, removing items from the Product Backlog
• Estimating Effort (doesn’t have to be story points)
• Updating the Strategy (i.e. Story Map) as needed

Problem 1: Backlog Refinement Meeting Drags On Forever

Long meetings are exhausting. I’ve never heard anyone say, “I attended a 3hr refinement meeting, and I’m glad I did.” Remote meetings make an already difficult activity even more challenging.

There are a couple of tactics I recommend in every CSM and CSPO workshop.

• Split the meeting into parts - max each session to 60 mins. Plan for 3 sessions in a Sprint, and tell the team that if they’re really effective, they can get the job done in 2.
• Ask the team to come prepared. Invite them to spend 10 mins reviewing the upcoming Product Backlog Items (or User Stories) and thinking through any questions they have.
• Learn what the discussion around a good User Story looks like. I.E. after 5 minutes, the team is mostly done discussing the User Story. Use this as a rough guide. If the discussion is taking longer than 5 minutes, ask the team whether they expect it to finish soon. If not, offer to table the Product Backlog Item for another time. I usually frame it like: “Perhaps this one needs some more digging to clarify key details, let’s bring it back in our next session.”

Silent Backlog Refinement Meetings - A Dream or Nightmare?

Amazon starts every meeting with a table read, everyone reads a six page document silently. Attendees take up to 25 minutes to read the document. Only after everyone has finished reading, does discussion begin.

The idea is that reading is faster than listening and helps non-native speakers engage. Arto Kiiskinen adapts Amazon’s Table Read to Backlog Refinement. Silently read a list of Product Backlog Items; add comments/questions; annotate each other’s comments/questions with: “Don’t understand”, “Agree”, “Strongly Disagree”. In this case, the focus is on the User Story as a written document.

I’m troubled. User Stories are not intended to be read. They are intended to be “an invitation to a conversation”. User Stories were invented to avoid the challenges of written requirements, and here we’re full circle.¹

Movement in Backlog Refinement

Chris Sims reminded me that we didn’t evolve to sit all day. Sitting down for even 60 minutes can be tiring. Change the energy, get up and move around. Lead by example, do it yourself first.²

Problem 2: Estimation Wars Eat Your Week

People have died in the wars fought over estimates. (Ok, not literally, but it feels that way.) Planning Poker was invented to avoid endless debates in meetings. Imagine it like colours. The first team member says, “Green”, the second says, “Chartreuse”, the third says, “Olive”. The debate will continue forever. The answers are close enough that it doesn’t matter.

James Grenning invented the tool to solve this problem³. The irony, of course, is that we’ve all seen Planning Poker turn into a game of endless debates.

The problem is that Story Points were supposed to be relative estimates. However, when a new person joins the team, the first question they ask is, “How many person-days is a Story Point here?” The magic of relative estimation is lost in that moment. There are many sources of this problem:

• Leadership focusing on velocity, not value
• Increasing pressure to go faster (a problem which GenAI is just making worse)
• Feeling that we must cram more into a sprint
• Pretending that better estimates will make us more predictable

Replacing Story Points?

Try Complexity Poker, where the first question is which Cynefin problem domain does this item belong to?

• Clear - we’ve done this so often before, we know exactly what needs to be done
• Complicated - we understand the core idea, but there are some unknowns, either business or technical
• Complex - we don’t know what needs to be built or if it is technically possible

Many estimation problems arise because we try to estimate Complex items that require experiments with prototypes, with Story Points that work best for Clear problems.

Items that are Clear could be estimated just by comparing them to similar items in the past.

Complicated items should be broken down into items that are small enough for a few people to implement in a few days. (Often called a T-shirt size of Small.) Complex items need experiments to understand: Should this be built? Do we know how to build it?

Instead of Story Points, consider using T-Shirt sizes: Small, Medium and Large. Small is well-understood, we can easily complete 5-10 of them in a Sprint; Medium is more complicated, likely most of a Sprint; Large is bigger than a Sprint. We should always have enough Small items at the top of the Product Backlog to fill a Sprint.

Magic Estimation

Put columns on the wall for each category: Small, Medium, Large or 2, 5, 8, 13, 20. People grab an item from the Product Backlog and place it in the column they think it belongs in. If no one wants to move it then it’s in the right place. If it gets moved more than once, then we don’t know what it is.

I first learned about this approach from people at Rally Software (remember them). I’ve heard it called Bucketing, Wall Estimation, and Affinity Mapping⁴. Barry calls it Magic.

Context - use when you have a larger volume of PBIs to rapidly sort through: 1 1/2 -> 4 mths worth. This is focused on speed over precision.

Problem 3: Not Ready and Wrong Attendees (Team Doesn’t Get It)

Backlog Refinement is a whole team activity. Not just the Product Owner and a few senior developers. When you don’t have the whole team involved, you’re missing out on additional perspectives; the others don’t understand what needs to be built, and it’s demotivating because they feel excluded.

Domain Knowledge

The team can’t refine what they don’t understand. When candidates fall outside their domain, bring in a stakeholder or subject-matter expert before the session stalls. Use that conversation well. Stakeholder input often reveals something else: items on the backlog that are no longer relevant and are just adding noise.

If an item has been in the Product Backlog for more than a few months, then it is time to ask: “is it really valuable?” If not, remove it.

Disconnect from the Strategy

The Product Owner needs a clear strategy that helps the team understand the direction of the product. I recommend Story Mapping as a way to visualize the strategy. When the team understands the strategy, they have a better understanding of where the item that is being refined fits into the overall product.

Not Ready

If we frequently have items that aren’t well understood, some teams create a Definition of Ready. I’m not a huge fan, as it can become a gatekeeper. However, it can be helpful to have a simple rubric to make sure a PBI is ready for the team to discuss. For example:

• Pencil sketch of any UI changes
• Happy path examples

Not a Meeting

Not all refinement sessions need to be a formal meeting. Some refinement, can just be the Product Owner reordering the Product Backlog or deleting an item; telling the team about the changes afterwards.

Refinement isn’t a ceremony to survive. It’s the work that makes everything else possible. Get it right and Sprint Planning becomes almost boring — in the best way.

If these problems sound familiar, there’s more coming. Part 2 will cover: Anti-patterns, Lack of Visibility and Stuck on Subscribe below and I’ll send it to you when it’s ready.

And if you’ve solved one of these problems in a way I haven’t covered, I’d like to hear about it: @mlevison@agilealliance.social and LinkedIn.

Related

• Product Backlog Refinement in Action

Footnotes

1. Arto Kiiskinen, Silent Backlog Refinement Meetings ↩

2. Chris Sims, Five Steps to a Better Refinement Meeting ↩

3. James Grenning, Planning Poker ↩

4. Barry Overeem, Magic Estimation ↩