 Seven ways to slash your product backlog. Good product owners know what's needed, but great product owners know what can wait. Once upon a time, a product owner, a client I was working at, asked me how many items I recommended he had on his product backlog. Now, as a consultant, my natural answer was it depends, but I did follow up with another question, which is how many items do you have at the moment? Now, his response was about 3,000, and my initial shock was huge because it wasn't a massive product or anything, it was just simply an internal trading system. But you never know, perhaps my instinctive response wasn't correct. So I asked, how many product backlog items does your team typically manage to complete in a sprint? And he had a think and he said about 20 to 30. I think we got 40 once, he said. So my maths, basic maths, says that that's about a hundred sprints worth of work provided nothing new ever gets added to that product backlog. Now, there's no real rule about it, but it did feel like at least some of that stuff had a pretty good chance of never getting done. And that product owner had to maintain that product backlog forever for no real value. And it turned out that he felt the same, but he was looking for a bit of validation or permission maybe to start cutting that product backlog down to size. But why is it important to keep your product backlog at a manageable size? Like I said, there's no rule that says you have to keep your product backlog to a certain number of items, but there are a few potential benefits if you do. First of all, the more items there are on your product backlog, the harder it is to work with. It's harder to find stuff. It takes longer to prioritize and reprioritize, takes longer to estimate. And overall it just becomes quite an ominous, imposing, demotivating presence for you, the product owner, and also the team. And it's a slippery slope. You know, the bigger it gets, the faster it becomes even bigger, because it's much harder to find overlapping items, so you just create another one, so you're accidentally creating more duplicates or semi-duplicates. And to be honest, when you're at 2,999 items in the product backlog, what's the harm in adding one more? So it quickly, quickly grows. Another benefit to cutting that product backlog is to kill people's hope. Now that might sound strange, but bear with me, because as long as something's in the product backlog, someone somewhere is living in hope that it'll get delivered. And they're probably wasting their time lobbying for it to become a higher priority, checking in on progress, when in reality, there's no hope it'll ever get done. So just free that person up from that false hope. Tell it like it is. So perhaps you want to start cutting your product backlog, but you're not sure where to start. Well, the good news is I've got seven tips to help you slash your backlog into a manageable state. And the first one is just do it. I've worked with a lot of product owners who've just decided to delete half of their product backlog because it had become obvious to them it was never all going to get done. And they figured that if it was really important, at some point, someone would come along and shout about it again. So actually in reality, they didn't delete them. They just archived them off to a separate list somewhere. Which brings me on to tip two. And this comes from Mike Cone. He talks about a holding tank, which is a place where you can put things that you're not quite ready to work on, but you don't want to lose. And Mike says the difference is that the product backlog contains all the things the product owner wants and can answer questions about right now. Well, the holding tank contains the other things that you probably want, but you either haven't thought them through in enough detail or you might decide they're not needed after all. My third tip is to focus on goals. And a great way to make the product backlog more manageable is to filter it according to the sprint or release goal and only show the items that are relevant to that goal. Move everything else to the holding tank. Tip four is to use some data to focus on an achievable amount of product backlog. So if you've got some empirical data of working with that team, then you might be able to use that data to only show an achievable or realistic amount. So say, for example, the team on average deliver about 40 points per sprint. You might choose to only show the most important 160 points worth of product backlog and then move the rest into the holding tank. Now, once you've done this big cull, once you've slashed your product backlog, you need to make sure you don't let it get into that state again. So tip five is to get into a habit, a ritual, if you will, of refining the product backlog. So set aside a certain amount of time, if you can, the same day every week, to go through and delete a few obsolete items on a regular basis. Or, coming onto tip six, merge smaller ones into epics. If you've got a number of small but related items sitting around near the bottom of the list, then you might consider grouping them up together into an epic, just a big product backlog item. Now, the same amount of work is still there, but it's just in fewer items, so it's tidier. And obviously, when you do come to work on that epic, you've automatically got away of splitting it into smaller achievable chunks of value. And splitting stories is another skill that great product owners work on. So check out my separate video on that. But my final tip, tip seven for slashing your product backlog is to time them out. Now, depending on what tool you use to manage your product backlog, you can probably identify the ones that are most appropriate to archive off. If they haven't been updated or asked about in a certain amount of time, then they're just automatically up for archiving. Just set up a rule to look at date, last, access or something, and time them out. And great product owners know it's easy to just say, I'll put it on the backlog. And they can justify it to themselves because we don't want to forget or lose any ideas about how to make our product better. But great product owners don't take the easy option. They're ruthlessly focused on what's right for the product. So if you want to become a great product owner, why not check out our product mastery pathway?