How Many of These Backlog Refinement Anti-Patterns Does Your Team Have?

In our workshops I often hear the complaint: “My team members don’t want to attend backlog refinement” or “Backlog refinement is frustrating because we’re constantly confused about what is important.”

In Product Backlog Refinement Hell: 3 Problems and Solutions we looked at the easiest problems to solve. Now we’ll look at the deeper problems.

Before we dive in, let’s do a back to basics check.

What is Product Backlog Refinement? It’s an ongoing process (strictly speaking an activity), where the team and the Product Owner review and revise the Product Backlog. They reprioritize items, delete items that are no longer important and add new items. As Product Backlog items move up in priority, they’re split into smaller, more manageable pieces. Items are estimated (hint: prefer T-shirt size estimates over story points). It’s not a marathon, instead it’s a series of conversations that happen throughout the sprint.

Why do we do Product Backlog Refinement? To ensure the team and the Product Owner have a shared understanding of the work that will be coming up in the next few sprints. To help the Product Owner make better business decisions, as they get feedback from the team on what is possible.

Problem 4: Zombie Items & Anti-Patterns Lurk (No Real Value)

How many of these anti-patterns do you see in your team right now?

Product Owner Challenges

• Micromanagement and ignoring the team’s feedback: these are two sides of the same coin. When the PO isn’t listening or is micromanaging, this is a longer-term coaching issue.
• PO is unprepared, or worse, absent? Cancel the session. There is no point in wasting everyone’s time.

Timing & cadence

• Refining too far ahead. Detailing items 6+ sprints out that may never get built.
• Running dry. Too little refinement, so there’s no ready work and Sprint Planning turns into emergency refinement.
• No decisions come out. Items leave the session in the same state they entered. Talk, no change.

The items themselves

• Nothing ever gets split. Items stay too big to fit a sprint, so they never become ready.
• Backlog as a dumping ground. It only grows, never gets pruned.
• Acceptance criteria gold-plating. PO writes 15 criteria covering every edge case, killing the conversation. Delay detailed discovery of the acceptance criteria until after Sprint Planning.
• Surface level understanding. Everyone nods that they understand the PBI, yet each has a different picture.
• Forgetting the User and the Why. We build products to solve problems for real people. The people and their needs should be front and centre in Refinement.

Estimation (beyond “only seniors estimate”)

• Anchoring. First or loudest number sets the estimate for everyone. When estimating, have people write down their estimate and then reveal at the same time.
• Estimates become commitments. A sizing guess hardens into a deadline.

Facilitation & dynamics

• Assigned Work. Refinement is about understanding the work, not assigning it. In Scrum there is no assigned work, period. Often paired with Drifts into Sprint Planning: deciding who does what and committing, instead of shaping work.
• Jumping to solution. Designing the “how” before anyone agrees on the “why/what.”
• Unbalanced Participation. This runs from near-silence on a PBI to a couple of voices dominating. This is often paired with Present but absent: people “attend” while buried in laptops and Slack.
• Limited Attendance. Only a few select team members are invited to attend.

I’ve made this case in more detail in GenAI Won’t Speed Up Your Scrum Events (and Shouldn’t).

The Liberators, Christiaan Verwijs and Barry Overeem, are famous (infamous?) for inventing the concept of Zombie Scrum. Zombie Scrum is where the team is doing all of the mechanics of Scrum, without any of the soul. Befitting the Liberators, they leaned into their community to find 8 tips (How Product Backlog Refinement Can Prevent or Fix Zombie Scrum). A couple of my favourites:

• Vote on which PBI is the least well understood. In the next session clarify or kill it.
• Bring the 10 lowest priority items to your next Sprint Review and suggest dropping them. If no one has a strong reason for the items, they should be dropped.

Problem 5: No Visibility Into the Mess (Can’t See Progress)

Blind refining? Visualize. Any Kanban board with multiple columns can give an organic, messy process just enough visible structure to track it.

Kent McDonald suggests a Kanban Board (Discovery Board) to help you visualize which Product Backlog items need refinement and which are ready to be worked on.

Since I like Story Maps, I might also consider adding extra lanes to the Story Map. Above a line the item is ready for Sprint Planning. Below the line, the item needs more refinement. We might also use colour: yellow for unrefined items, green for those ready for Sprint Planning.

CFD Tells a Story of History

Peter Callies shows how we could use a cumulative flow diagram to look back at a team’s history and sense how well refined the Product Backlog was at any moment: Visual Evidence of an Agile Release. The tell: watch the band of items waiting to be worked. If it keeps collapsing to near-zero just before each Sprint, refinement wasn’t keeping pace; a steady buffer means it was.

Problem 6: Stuck on Big Features (No Splits or Examples)

When you’re stuck and don’t have agreement about a feature, write an example. I’ve been saying that in workshops for years.

Write or Sketch an Example

In adult life, when we’re stuck in a conversation with another person, we often use an example to break the logjam. For some reason, when we’re working as a team, we forget to do the same thing. Examples can span a whole spectrum from:

• Pencil sketch of the User Interface
• A Happy Path, showing how a user would use the feature
• …more detail

In Backlog Refinement, my rule is just enough detail to get everyone on the same page. I delay writing detailed acceptance criteria until after Sprint Planning (see: Example Mapping: Your Secret Weapon for Effective Acceptance Criteria). If you want more inspiration in the same vein: Product Backlog Refinement in Action (Scrum by Example).

Story Splitting

Story Splitting is Yin to Example Mapping’s Yang. Christiaan Verwijs of the Liberators has a number of examples of using Story Splitting to break down complex User Stories. Even if the example splits themselves don’t work, sometimes the process of talking about why a given split doesn’t work is enough to find a better way to do this: 10 Powerful Strategies for Breaking Down User Stories in Scrum (with cheatsheet).

An Example of Putting it All Together

Kent McDonald worked with the Agile Alliance to improve their search functionality. “How To Refine Features” tells the story of that process, from desired Outcome to first delivery.

The Wild Card

35 Cards to Provoke Engagement. 35 Cards to hand out to team members during Product Backlog Refinement. These cards are intended to provoke engagement and get people to think about things that get forgotten. I like the idea of asking people to take on a role as a way to get them more engaged in the conversation. Some good ones are:

• Time Tracker keeps track of how long the discussion has taken on a given item and tells the team when they’re in overtime.
• Big Picture describes the overall purpose of the feature/user story that we’re discussing.
• Joker raises a flag when the discussion is going off track or getting bogged down in too much detail.

The only thing I don’t love about these cards is that a number of them bleed into Sprint Planning. For example: Point Blank is about committing to work that is realistically achievable in the Sprint, or Challenger asks the team if they’re sure they can finish “all the work they just committed to.”

Conclusion

Poor Product Backlog Refinement is a leading cause of poor Sprint Planning and overall crappy products. In a world where we do more work with Generative AI, Product Backlog Refinement will become even more important. Instead of trying to speed up the process, we need to focus on ensuring that we’re building the right thing.

Done well, Product Backlog Refinement can be an engaging activity that gets team members on the same page. If you want to go deeper on shaping a healthy Product Backlog, my Certified Scrum Product Owner (CSPO) training spends real time on exactly these skills.

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