Your product backlog is probably too long. A quick way to tell is to look at the items at the bottom of your backlog and consider two questions: do you know their origin (who requested them and why), and assuming the team works through the backlog and eventually completes those items will they still be valuable? There’s a good chance that the answer to at least one of those questions is no, and that’s an indication that your backlog needs attention.

I often refer to Henrik Kniberg’s “Agile Product Ownership in a Nutshell” video because he covers so many key points, especially the need for the PO to say “no” so that the backlog remains relevant and realistic. The backlog should not be a place where ideas go to die! When a stakeholder says “I really need feature X” they’re probably hoping to see that feature delivered in a few weeks or maybe a couple of months – if the PO has to tell them it’s going to be 6 months or more, then why are we doing agile?

Aside from the benefit of setting realistic expectations with your stakeholders, keeping your backlog brief makes it easier to see what’s there. (This is especially useful if you use a tool like Jira which randomly adds new items to the top or bottom of the backlog!) There is also less effort invested in creating those backlog items, which means there’s probably less resistance to throwing them away when the direction changes. The same can be true for the sprint backlog. If your sprint backlog is long and unwieldy then the root cause may be that the team are breaking things down into overly detailed tasks, over committing in sprint planning, or have too much capacity (e.g. sprint is too long, or too many people in the team).

One concern I’ve heard about having a short product backlog is that it doesn’t give the team a sense of long-term stability, e.g. the team may be disbanded (or even laid off) once everything in the backlog is done. However, I think if the team are concerned about their future then there are bigger issues to address than the backlog, and artificially adding items to try to calm the team is disingenuous, contrary to the openness and honesty we promote.

The Scrum Guide describes refinement as “the act of breaking down and further defining Product Backlog items into smaller more precise items”, which is usually how product backlog items are made ready for sprint planning. I think what’s missing is the attention that a PO gives the product backlog, maybe in conjunction with the stakeholders, to prune the backlog in order to keep it focused on the upcoming needs – probably the largest part of the PO role is the communication with the stakeholders, and I think Henrik’s video gives a great overview of how much happens often without the team’s knowledge.