When you have the right detail at the right time, backlog refinement feels more like purposeful elaboration than like uncontrolled churn. You don’t have to spend time refining things that’ll never get implemented.
Backlog refinement shouldn’t be the most painful meeting of the week—but for many teams, it is.
Too much detail too early. Vague stories. Half the team checked out. And eventually, no one shows up at all.
In this episode of the Humanizing Work Show, we’ll show you three practical changes that turn backlog refinement from a dreaded chore into a valuable, collaborative part of your Agile process. These tips will help you reduce churn, strengthen stakeholder relationships, and make sprint planning smoother.
If you’ve ever found yourself wondering why Agile feels harder than it should, this might be the place to start.
Learn More
Episode Transcript
Peter: Too many people dread backlog, refinement meetings. They know what’s supposed to happen in those meetings: take a look at what’s coming up in the backlog, make sure we all understand what the items are, clarify the success criteria, maybe add some detail, figure out how to split items, estimate ’em. But their actual meetings rarely look like that.
Stories aren’t stories at all. They’re either completely vague, like some shorthand note with a confusing title, or a long detailed request or specification. Some items represent a huge complex business goal. Other items, just say fix bug #22567.
And the meetings themselves are, to put it kindly, poorly facilitated. The team goes item by item with only one or two people talking through the specifics and typing in a tool while the rest of the team tunes out and waits for the next item to come up for discussion. Eventually people start missing the meeting due to other conflicts.
Richard: And this makes everything else about their approach to agile less effective. Planning meetings take too long. Details emerge in the middle of a sprint that could have easily been discovered with a simple discussion during refinement. Reviews get contentious since no one aligned on what a good outcome would be. And with backlog refinement becoming the most frustrating part of the week, a lot of people start thinking, ‘well, if that’s agile, I don’t want any part of it.’
But that’s not agile. That’s not what good backlog refinement looks or feels like, and you can change it for your team. Today, we’ll share our top three tips for how to turn backlog refinement from a dreaded inefficient waste of time into an ongoing collaborative approach that sets you and your team up to do meaningful, engaging work every day.
You know, like Agile’s supposed to do.
Peter: But before we share those backlog refinement tips, a reminder that this show is a free resource sponsored by the Humanizing Work Company, where we help organizations get better at leadership, product management, and collaboration. You can schedule a conversation with us on our website, humanizingwork.com, to talk about how your organization can get stronger results in those areas.
And if you wanna support the show, the best thing you can do if you’re watching on YouTube is subscribe like the episode, and click the bell icon to get notified of new episodes. Drop us a comment with your thoughts on today’s topic. If you’re listening on the podcast, a five star review makes a big difference in whether people find us or not.
Richard: Our first tip for better backlog refinement isn’t about refinement meetings at all. It’s about shaping the backlog itself to make refinement more incremental and more efficient. Structure your backlog with the right level of detail at the right time, and it’ll tell you what needs to be refined, when, and how.
Most backlogs we see have too much detail too far in the future. This is wasteful and it’s bad for the Product Owner’s relationships. It’s wasteful because many of those items further down the backlog that get refined in detail will turn out to never make it to the top of the backlog. Or they’ll have so much change in the details before they get to the top that they’re unrecognizable.
You’ll have spent time talking about and writing down details that turn out to be irrelevant or wrong. You’ll often hear this referred to as churn in the backlog.
Peter: And it’s bad for stakeholder relationships because as backlog items become more detailed, they start looking more and more like promises. And the churn in the backlog that’s inevitable when you plan too far ahead, ends up feeling like a lot of broken promises.
Stakeholders begin to wonder if it’s really worth the time to engage with this Product Owner on the details of their initiative or feature. Maybe they should just go directly to a developer that gets things done.
It’s bad for a PO’s relationship with their team because churn in the backlog signals that the PO doesn’t really know where to point the team’s efforts. And if the team loses trust in their PO, their motivation goes down and they’ll often start working on backlog items out of priority order, focusing on what seems most interesting, most important or efficient to them, or even responding directly to those stakeholder requests in an effort to get a sense that their work actually matters.
Richard: When you have the right detail at the right time, lots of details leading up to the next sprint. Less detail in the middle of the backlog, even less detail toward the bottom of the backlog, backlog refinement feels more like purposeful elaboration than like uncontrolled churn. You don’t have to spend time refining things that’ll never get implemented.
Plus, when you structure a backlog this way, the backlog itself tells you what needs to be refined and when you should stop refining at a certain level of detail, for now.
Peter: Check out our PO board episode and infographic for more details about how to structure a backlog with different levels of detail on those different timeframes.
Okay. Tip number two: refinement goes better when everybody understands what done looks like for backlog refinement. So get clear on what refined means, which doesn’t always mean detailed acceptance criteria.
Richard: When you’ve structured your backlog with just enough detail for different timeframes, you need to know and align on what sufficiently refined means at each of those states.
How much detail and what kind of detail do we want in an item at the bottom of the backlog, in the middle, at the top? How will we recognize when we’ve achieved that level of refinement?
Peter: Which are tricky questions to answer, right? The more we try to come up with a set of rules or definitions of done, the worst things tend to get. It almost always leads to over analysis and too much detail in your backlog, too far out.
Richard: Yeah, that’s right. Too often when people try to define what they mean by refined, whether that’s a definition of ready at the top of the backlog or the equivalent for some earlier state, further down the backlog, they can end up listing every kind of detail they might wanna include in that kind of backlog item, and then turn that into a checklist.
Instead, we recommend thinking about the backlog as a product. So think about the jobs that different people will do with the backlog items at each stage in a backlog, and then ask, what’s the minimal information that’s needed to do those jobs?
Peter: Yeah, let’s look at a few examples. Here’s a pretty common one: a salesperson wants to know whether a frequently requested feature is likely to be released by the time they have their next sales call with a specific client. You don’t need all the details to do that job. Just feature names and short descriptions.
Or other teams working on related things might wanna see the timing of dependencies. So they’ll need, again, some info about what the items are, and they’re gonna need some confidence in estimates and forecasts as items approach the top of the backlog.
The development team’s gonna need enough info to feel confident about how much work will fit in those sprint, but they don’t need all the details to be able to complete the work independently until they’re ready to actually work on that item in the sprint.
Richard: And maybe not even then because one thing to watch out for, especially at the top of the backlog, is that complex backlog items are going to have details emerge mid sprint.
So make sure your definition of ready going into Sprint Planning can handle the differences between complex and complicated items. Many of our clients tag their backlog items based on whether they’re complex or complicated, and then apply a different definition of ready to each type.
Complicated items can have a lot of detail going into a sprint. That Product Owner should do their homework and document known business rules, data variations, user scenarios, things like that. Those backlog items should be pretty predictable in the sprint and shouldn’t change much.
Complex items though, especially with business complexity, are going to go into a sprint with a certain amount of unknowns. More collaboration is gonna be necessary to get to done, and the details are likely to get negotiated during the sprint. It’s not unusual to see a complex backlog item get split mid sprint with the core part staying in the sprint and variations going into the backlog for later. Those complex items will have enough details to define what the item is, maybe how the team will start, but they’re not gonna have a complete specification of the details.
In fact, I’m not a fan of the term acceptance criteria for this kind of complex backlog item. I think it implies too much certainty in advance about what acceptable will look like.
Peter: Okay, for tip number three, let’s talk about the backlog refinement meeting itself, and here’s our advice: don’t have a backlog refinement meeting. Instead make refinement a collaborative ongoing activity, not a meeting.
Richard: Almost everyone we talk to describes backlog refinement as a laborious chore that no one enjoys, and most of the time they’re describing a weekly meeting where the team moves through Jira tickets one at a time, and you watch somebody type and dictate what’s in the card.
We’ve discovered that most of what gets discussed in a backlog refinement meeting is better in smaller conversations spread over time. A few people can work together to split a large item. A discussion about a feature can easily pause for further research when it becomes clear that the answers aren’t in the room. Different people can engage with different items where they have time and expertise.
Peter: In fact, the only refinement activity we still think requires the whole team is estimating work. Everyone should own the estimate. This also ensures that the whole team at least talks about every backlog item, creating the alignment you need for effective forecasting and Sprint Planning.
Richard: You can use your Daily Scrum to coordinate incremental backlog refinement. The Product Owner can bring backlog items that need discussion and schedule those with the appropriate people. They might say something like, ‘Hey, I have this new story related to the payment capability in the system coming up the backlog, and I think it’s probably too big. Are there a couple people on the team who can spend 20 minutes with me today to help me split it. Um, who has time and when would you like to do it?’
Peter: Or if the team has a few stories to estimate, you can discuss that at the Daily Scrum and plan an ad hoc, maybe 20 minute discussion later that day, rather than having a weekly, way too long estimation meeting that recurs on your calendar.
Richard: Yeah, estimating a story or two every few days is a much better approach than slogging through a dozen stories in one long, drawn out meeting. We actually see a lot of teams do that quick estimating right after the Daily Scrum, since they’re already scheduled to be together as a whole team. And that’s especially true if they’ve applied the tips from our Daily Scrum episode to have a shorter and more productive Daily Scrum, so there’s time for that.
Peter: So try one, two, or if you’re ambitious like me, all three of these tips to turn backlog, refinement around for your team. Structure your backlog with the right level of detail at the right time. Get clear on what refine means, but don’t forget about complexity, and make refinement a collaborative, ongoing activity, not a meeting.
Richard: What else have you tried to make backlog refinement more effective on your team? How did it go? Tell us about it in the comments on LinkedIn or YouTube, and thanks for tuning in to this week’s Humanizing Work show. We’ll see you next time.
Last updated