If you’ve ever tried to trim a pet's toenails, you probably have negative associations with grooming. And if you've ever been in a backlog refinement meeting, that negative association with grooming probably goes for double.
For many software development teams, backlog grooming, or, as it’s becoming more commonly known, backlog refinement, is seen as a necessary (and sometimes unnecessary) evil. How can we make backlog refinement productive and enjoyable again? Maybe that's asking too much. Let's rephrase that:
How can we make backlog refinement productive again?
It feels like such a waste to sit in a pointless meeting with nothing to do. We really, really hate to come out in favor of meetings in any way, but if you think backlog refinement meetings are painful, try not having them. Here’s what you have to look forward to if you don’t refine your backlog before planning your next sprint:
What we’re saying is, if you don’t have backlog refinement, you aren't as likely to deliver good software. But before you argue that backlog refinement should just be an asynchronous activity and not a soul-numbing meeting, let's explore why you might currently hate backlog refinement.
Since you're still reading, let's assume you at least kinda hate backlog refinement. Good! It's important to have things to hate. How can you truly appreciate what's good in life if you don't have things that you hate to compare them to?
Hating backlog refinement is also the path to fixing what’s wrong with backlog refinement. The things you hate about it are the same things that make it ineffective. Stop doing those things.
There’s a special place in hell for meetings that should have been emails. When your backlog refinement meeting is anything less than a time of engagement and productivity and fun, it sours everything else about backlog refinement.
If you’re not sure if your company’s backlog refinement meetings are guilty of this, just ask yourself and your team if any of these sounds familiar:
These are clear warning signs that your approach to backlog refinement is flawed. To figure out what, in particular, is flawed, you’ll have to dig a little deeper.
The mindset you take into backlog refinement can determine what you get out of it. Any of the following thoughts sound familiar?
“When will this be over so I can get back to work?” This mindset means you’re focused on output when you should be focused on delivering value. If figuring out how to best deliver value isn’t your goal, you’re not going to get much out of this. Of course, this can be difficult to do if your meetings suffer from the problems noted above.
“Time to hand out a bunch of tasks!” Sometimes the product owner is the culprit here, and sometimes it’s the team. No matter whose fault it is, treating it like a time to give out homework assignments makes it feel like busywork.
“My opinion doesn’t matter.” Backlog refinement only works when everyone involved is engaged and empowered to share their perspective, ideas, and concerns. If the team doesn’t feel like they can safely share their thoughts, or if a few voices always dominate, then what's the point of having everyone meet?
The product owner can absolutely make or break the backlog refinement experience. If they're not on their game, everyone is going to hate the process and maybe hate them too. There are five ways in particular that a product owner can ruin backlog refinement for everyone.
1) They micromanage. Does anyone on earth like being micromanaged? Backlog refinement is supposed to be a collaborative process, not a task-management session. A product owner who uses it as an opportunity to micromanage everyone's schedule is going to ruin things.
2) They’re MIA. Ah, yes, the complete opposite of micromanaging. The product owner is supposed to own the backlog. A development team left to their own backlog refinement might feel more free, but they will inevitably run into quality and dependency problems in their sprints if the product owner isn’t involved. Management roles do exist for a reason other than approving time off requests.
3) They’re unprepared. When the product owner doesn’t prepare in advance, everyone’s time is wasted—often helping the product owner do the pre-work they should have done to make the meeting productive. The product owner should have an agenda laid out beforehand and control the meeting so it doesn't go over or end up dominated by one or two people.
4) They try to do it alone. The whole point here (which we've probably made very clear at this point) is to have input from multiple team members and project stakeholders so that sprints run as smoothly as possible. Backlog refinement from a single perspective—no matter how experienced—is not sufficient.
There’s a fine balance between owning and driving backlog refinement while recognizing and facilitating the input and strengths of others. Product owners must strike this balance, or backlog refinement will continue to be hated.
Backlog refinement will be one of the most frustrating experiences of your career if you don’t take the time to make sure everyone shares the same Definition of Ready. Your backlog refinement should be working toward getting stories as ready as possible before your next sprint—and for that to happen, you have to know what “ready” means.
It’s easy to assume that everyone knows when a story is ready—shouldn’t it be obvious? Because it’s easy, it happens a lot, which can make backlog refinement feel eternal. Without an agreed-upon definition of ready, you’ll either be spinning your wheels or admitting stories into your next sprint without proper definition.
It's possible to go too far in the other direction and overly define your backlog so that every task is completely mapped out. Don't feel pressured to do perfect your refinement process.
As you move through your product roadmap, you’re going to continually adapt your approach and priorities based on feedback from the customer, another team, and even your own experiences. A fully refined backlog steals precious time and focus from important tasks—and all for stories and features that will likely need to change in the future anyway!
Now that you know what you’re doing wrong, it’s time to stop doing the things people hate—and start doing things that they will like instead by making them feel invested and engaged in the process.
What preparation looks like will vary between companies, people, and projects, but the basic rule is this:
The product owner should prepare enough to at least know what the team needs to discuss, who needs to be involved in backlog refinement for this sprint, and how to get the input they need from the team. This usually involves framing out some basic details for features and stories and preparing discussion questions to make sure everything important is covered and the meeting doesn't simply take a life of its own as other topics rise up to fill the empty space left by the lack of planning.
When assembling your backlog refinement team, look for diversity of experience and perspectives, but also remember Jeff Bezos’ rule about team size: Your team should be small enough to feed with two pizzas, three party subs, or four bags of McDonalds hamburgers selected at random by an artificial intelligence. Hmmm, actually not sure that Jeff Bezos said ALL of that.
Ideally, you want a 360˚ perspective on upcoming stories so that you can prepare for your next sprint as thoroughly as possible.
But inviting the right people isn’t enough. You also need to nurture the right soft skills so the team can engage productively. There are no shortcuts to building these kinds of soft skills, and no substitute for them either. Improving communication skills is the most effective place to start.
To make backlog refinement as productive as possible, don’t look too far into the future (ideally, no more than four sprints ahead). Focus especially hard on your next sprint and make sure it’s ready. Time permitting, you can look one or two sprints farther. Just remember what we said earlier: an over-refined backlog can be just as problematic as an under-refined backlog! You risk wasting a lot of time and energy if you work too far ahead.
When it comes to scheduling backlog refinement, aim for the middle of your current sprint (for example, day 6 or 7 of a 10-day sprint). You want enough progress on your current sprint so that you can accurately judge what changes or challenges you might face with backlogged stories. You also want to leave plenty of time before your next sprint begins so that you can prepare for it.
Backlog refinement that’s valuable to everyone is backlog refinement that ends with everyone on the same page. We already talked about what happens when your team doesn’t have a clear Definition of Ready. But you should also use this opportunity to define acceptance criteria for every backlogged story you groom.
Just like your Definition of Ready unites your team on when you’re able to start a story, having acceptance criteria ensures that everyone understands what it will take for this story to be completed. If you have kids or roommates or a partner (or potentially all three if you live anywhere near San Francisco), chances are that your definition of a clean house and their definition are very different—which probably frustrates all of you. Defining acceptance criteria during backlog refinement gives the whole team confidence and clarity when moving forward.
The key to making backlog refinement valuable and engaging is to make the value to the team obvious. Remind your team of, and refocus them around, the goal of delivering value to the business and the customer. Backlog refinement isn’t something to check off a list—it’s an opportunity to refocus everyone on the value of the work you do day to day.
It’s tempting to get lost in the minutiae of running the meeting—adding the right amount of detail, assembling the right team. But the best way to ensure productive backlog refinement is always to bring it back to the central question: “How is this delivering value? What value is it delivering? Who is it delivering value to?”
Improving your backlog refinement process will potentially not only align your team but excite them as well. Wait, no, we did not just say that. Improved backlog refinement will excite your team? It will! There are very few things that are more exciting in a work environment than feeling like a meeting was not a waste of time. One of the things that is more exciting? Getting more stuff done and accomplishing more goals.
Backlog refinement can give your team a renewed sense of purpose as they approach the next iteration of a project. It does this by giving everyone a voice and uniting them around the next steps.
So remember: If you hate backlog refinement, it’s probably because you’re doing it wrong.
And if you’re currently doing it wrong, refine it and do it less wrong. It may take a few sprints to get right, or, more likely, it may take every sprint to get right because you'll be working to improve and refine it with your teammates as you react to what works and what doesn't.
Nothing to see here...