The backlog that almost killed our team

Let's talk about specific techniques to keep your backlog healthy. When I worked at a financial services company in Southern California, we had this massive backlog with hundreds of items, feature requests, bug fixes, technical improvements, you name it. The problem is, it was just too big. No one knew everything that was in it. And it had duplicates. I can remember because people would say, hey, is this already in there? I don't know. We better create one just in case it's not. And. And then we would end up with duplicate entries. Well, that's absurd. Well, the development team was overwhelmed. Our stakeholders were frustrated because their pet features weren't getting attention. And I was drowning in meetings trying to explain why we couldn't get more done. So we hit the reset key for every current backlog item. I asked one simple question. Which of these items directly helps our customers close more loans faster? That's it. That question. It changed everything. We removed about 70% of our items in one meeting. The remaining 30% were clearly tied to our product vision of helping loan officers process applications more efficiently. Now, inevitably, someone will say, hey, should we just hang on to that item instead of deleting it? What if we need it later? My answer to this has always been, if it's important, it will come back up. So I'm a fan of just deleting it. Now, that meeting I described, that was just one way to refine a backlog. In fact, it's sometimes referred to as a backlog refinement meeting. On most of the teams I've been around, this is a recurring scheduled event where the teams get backlog items ready for development. Now, when you're starting out, I recommend with 90 minutes once a week, pick a recurring day and time and then adapt as you get better at it. And here's a sample agenda you can use. In the first 15 minutes, review the last Sprint's feedback and any new items that you're bringing in. And in the next 60 minutes, do a deep dive into the highest priority items. You might get through two or three or four of these. You'll just have to get used to it as time goes by. But it's during this time you're going to want to accomplish a number of things. First, have the product owner explain the why behind each item and its business value. Then, get your developers involved. Have them start asking technical questions about the implementation. Have testers probe edge cases and testing scenarios. Break down large items into smaller manageable pieces. Identify and document dependencies. Discuss acceptance criteria in detail. What exactly does done look like Review or create any needed mockups or wireframes. If the team feels they have enough information, estimate the work, capture any assumptions we're making, and document any technical research needed before we can fully understand the work. Okay, then in the last 15 minutes, we do a quick stacking of hands and make sure we all have a common understanding. You might do a quick Roman thumbs vote where the team members vote by using their hand. You know, give a thumbs up or a thumbs down or a horizontal thumb if they're undecided. Quick way to get consensus. So that's a backlog refinement event. But that's not the only way to keep your backlog healthy. Another powerful technique I've used is what we call the three amigos approach. This is where we just have three people. The product owner, a developer, and a tester gather together to review backlog items. Each of those people bring a different perspective. The developer might spot technical challenges while the tester thinks about edge cases and validation. And you as the product owner, will you ensure it aligns with user needs? You want to think of backlog refinement and elaboration like turning all the lights on in a dark room. We want to illuminate as many unknowns as possible before the team commits to building it. Let me share something else I learned at that financial services company. After we did that initial cleanup, we didn't just stop there. We had to keep the backlog healthy. Every month we'd look at three things. What are we hearing from our customers? What's changed in the market, and how well are our recent features performing? For example, we noticed that loan officers, they were spending a lot of time re entering data from PDF documents. Well, that wasn't in our backlog initially. But after seeing several customers struggle with this, we added items for PDF data extraction. And on the flip side, we had several items about enhancing our internal reporting dashboard. But when we looked at usage data, we found that managers barely use those reports. Those items, they didn't align with our vision of helping loan officers close more loans faster. So we removed them. Now let's think about Task Nova for a minute. This might mean adding items based on customer support tickets or removing features that aren't being used, adjusting existing items based on user feedback and adding new items to respond to market changes. The key is to make this a regular habit. In my experience, a monthly review works just fine. It's frequent enough to stay current, but not so frequent that it becomes overwhelming. Remember, a healthy backlog isn't about having the most items it's about having the right items. The items that support your product vision and meet your customers evolving needs.