If you’re familiar with Agile ceremonies, you’ve likely heard of backlog grooming, also known as backlog refinement. I love a good spoiler, so I will share right here at the beginning of this article that the number one mistake I see in backlog refinement is that it doesn’t actually happen. Since there’s usually so much work to be done, it’s easy to want to jump in and start planning sprints right away; but backlog refinement comes in first to ensure your team can succeed at sprint planning.
So, let’s take a look at why backlog refinement is independently important, what a meeting looks like, and address some other common mistakes along the way. We’ll look at how this plays out in both a perfect world (as we see in just about any pop culture reference) and what we typically see in real life. So sit back, we’re going on a little adventure.
What is backlog refinement?
Backlog refinement (or backlog grooming) is a process where both the product owner and agile team members meet to review the list of the work that needs to be completed within the project, also known as the backlog, so those work items can have detail added, be split or decomposed, estimated for effort and complexity, and be evaluated for necessity.
Why and When Do We Perform Backlog Refinement?
Backlog refinement is important for providing necessary information to help with sprint planning. Backlog refinement should be held before sprint planning because we want to make sure that all items in the backlog are actually ready to be planned. It’s difficult to plan for something when we don’t know what kind of effort it will take to complete a task or what actually needs to be done. Likewise, it would not be a great use of time if we tried to plan something that didn’t need to be done either. In the real world, where the average cost for avocado toast is more than $6, it’s more common than you think for organizations to either not go through product backlog grooming at all or to combine it with sprint planning. Basically, it would be like trying to watch The Hunger Games: Catching Fire without having read or seen the first one. We can do it, but we wouldn’t be getting the “full cinematic experience”. If we go into sprint planning without more clarity around work items, it’s going to be difficult to plan accurately. We’ll plan it, but there will be a lot of factors that weren’t considered or planned for that could come up during the sprint.
On the other hand, sprint planning is when we actually plan the scope of the sprint. This is where we discuss the goal of the sprint, prioritize the work, decide which items from the backlog will be included in the sprint based on team capacity and velocity, and identify tasks to be completed. As you can imagine, trying to do all of that with a backlog that might still have items that don’t even need to be done or that don’t have enough detail would be about as productive as going through our junk mail. We’re doing it, but it’s not serving the purpose that it should.
While very small projects may be able to combine backlog grooming (refinement) and sprint planning, its usually best to separate backlog refinement and sprint planning so that each ceremony is given the proper amount of time and attention. Each meeting serves both a specific and important purpose in an agile environment, and creates the opportunity for scalability in the future.
What does a backlog refinement meeting look like?
This will look different depending on the project, organization, team, and product itself, but generally speaking, and in a perfect world where Bella & Jacob are actually the hero couple of Twilight, the backlog refinement will incorporate the following questions to get the conversation started:
1. Does this work still need to be done?
Sometimes work or overall vision can change, especially in agile environments. Therefore, it’s not uncommon that a feature, user story, or task that was in the backlog may no longer be needed – similar to VHS tapes. When the team determines that specific work is no longer needed, associated work items are removed from the backlog. Aside from creating a cluttered backlog, leaving invalid work in the backlog makes it impossible or at least very difficult to have an accurate burndown for the project.
2. Is there enough detail/information to meet the acceptance criteria?
If there is not, the team should work together to add more detail/clarification to the work item. Imagine you’re writing an online dating profile and the picture of you holding a dead fish and description that says ‘hi’ is the only information someone has about you. It doesn’t really say a lot about you as a fully rounded, autonomous human being.
If you want someone to know anything about you, you have to put some information in there. User stories are no different (except you should NOT be trying to get dates with user stories – to be clear). The more detail you provide, the better chance you have of getting a result that you’re happy with. If we write the user story equivalent of ‘hi’ and a duck lip selfie, meaning, we don’t have acceptance criteria, we haven’t described what really needs to be done, or provided any requirements, how is anyone supposed to try to plan for that work? Even more, how are they supposed to actually complete that work? The truth is, it’s probably going to be pretty hard. If the work items don’t contain quality stories, acceptance criteria, requirements, etc, then those items, and the project are more likely to have high failure rates, which no one wants.
3. What is the complexity of each work item?
The most common way that this is done is through story pointing. During a project kickoff, the team establishes baselines for story points so the team can accurately estimate the level of effort and complexity moving forward. There will be some math involved (sorry!) and there are a few steps to take, but I promise it will help the team get an accurate estimation of complexity and effort of a work item. If you want to know a bit more about story pointing, there is a good article that goes into more detail than just “math”. Other common methods to estimate work complexity include: T-Shirt Sizing, Affinity Mapping, and Dot Voting.
Estimating work item complexity helps provide a common language for the team when we talk about complexity. For example, Derek Shepard may assume that a routine appendectomy will take approximately four hours to complete. But because he’s the brain guy, we want to get a more accurate estimation from Meredith Grey – the General Surgery rockstar – because she is trained to know the level of effort for that type of procedure; plus, we don’t want McDreamy worrying about the patient’s family. Let’s give them an accurate estimation before the surgery begins.
4. Does the work need to be broken down or split?
Ideally, a user story is written in a way where it can be completed within one (1) sprint. That’s our perfect world though, where shipping never costs more than the product you’re buying. Unfortunately, it’s an all too common problem in the real world where sometimes people take up two parking spots. It usually happens because there is a capacity issue, or the story was too large. This is also where I’ll make a second plea for estimation to happen during backlog refinement. If your team is making a large estimation on a work item, it should be broken down differently. Maybe that looks like a new epic or feature, or maybe that looks like more user stories. Each team and each project is different, but what they all have in common is the fact that everyone wants to have succeeded at the end of the sprint.
Typically, backlog refinement and sprint planning meetings are each scheduled for one hour per number of weeks in the sprint. So, you can imagine that if you’re combining 4 hours of meeting time for a two-week sprint into two hours, there’s a chance that you’re missing out on some valuable discussion with your team.
I know that a two hour meeting may seem a lot. We are all in too many meetings as it is, however, by spending the amount of time that is really only equal to watching two movies from the early 2000s, you could have your team set up for a successful sprint, which means you’re probably going to have less unplanned meetings throughout the sprint. #winning
So we feel good about backlog refinement and sprint planning now, but what about those of us who have massive backlogs that are out of control? You’re probably thinking that a standard backlog grooming session isn’t going to cut it. Honestly, you’re probably right. There are so many reasons that backlogs can become unmanageable. The easiest way to prevent that from happening is by doing regular backlog refinement. But if your backlog is already out of control, that’s not very helpful advice. If you’ve ever had a sink full of dishes, you know exactly what I’m talking about. So, for those who want to try to get their backlogs to a place where they can have those regular refinement meetings, here’s what I suggest:
- Combine duplicates – this might take longer than you think. You may have to talk to individual people to determine if certain work items are actually duplicates or not.
- Remove work that’s no longer needed – This will be similar to combining duplicates where you will likely have to talk to individual owners of the work items to determine if the work is still needed.
- Consolidate work items – How this is done will depend on the type of work item management system you are using, but you can work to make a hierarchy of items that go together. This will, if nothing else, help provide a more focused view of the work items for sprint planning.
- Have a process – Make sure you have a process for who creates work items, how they’re created, and what they’re created for. This will help ensure that all your hard work in cleaning up your backlog is worth it. After you establish the process, be sure it’s documented so you can easily find what works and what doesn’t work.
So there you have it, backlog refinement and a little extra bonus of backlog cleanup thrown in for good measure. Hopefully I’ve shown you that a more perfect world where Die Hard is included in everyone’s winter movie rotation, and backlog refinement is given dedicated time and attention is possible. Yippie-kay-yay Agile lovers.