Or “aggressive product backlog triage”.
In Scrum we know that requirements are tracked in the product backlog (actually it tracks more than that, but this subset of product backlog items is certainly there). If we are not careful, this quickly leads to the idea that the product backlog is where we do what we traditionally called “requirements management”. We end up with the idea that “if we think it is a good idea it should be on the backlog” which results in an ever increasing list of requirements. My view is that this is a problem as, as the list increases, we have an increasing number of backlog items that will never actually get implemented. But we still apply time to managing this list, working on improving how we track this list and so on. As Peter Drucker says “There is nothing so useless as doing more efficiently what should not be done at all.”
Think about some of the effort you will waste by managing a large list:
If you have items in the list that are not actually going to be worked, then you have a set of effort which produces no value. How much effort you have wasted will depend on what you have done. If you just wrote a user story, the effort is low. If you've defined Conditions of Satisfaction, or had the team estimate the item, then there is more wasted effort. You won't be able to get rid of all this wasted effort (for example, you might need an estimate on something to decide whether an item is worth considering) but if you do this for each and every item in the backlog it adds up to a lot of non-value producing effort. The question you have to ask yourself is this overhead of the big list worth the result. My view is that in most cases it is not, and that a more aggressive approach to maintaining the product backlog makes sense.
How do you clean up the list you have? In the first instance you will have a natural reluctance to delete “a perfectly good record” and so perhaps the best idea is to set up an “attic”. The idea behind the attic is that it is a special classification of product backlog items where, in the normal course of work, you never see the stuff that's in the attic. You then go through your product backlog and decide which items need to be put up into the attic. You will also need to make a call as to how (or perhaps a disingenuously whether) you will tell interested stakeholders about the disposal of their items.
The criteria for defining candidates for the attic will vary based on circumstances but here is a set of starting ideas. Firstly understand how much you will likely be able to do over a period of time to set an upper limit on how much should be in the product backlog. For example if you are working a single team, then use the velocity information over a time period of “the next couple of releases” to set an upper limit either in terms of number of stories or, more usefully based on the number of points that are in the product backlog. So if your team velocity is 50 on 4 week sprints and you have a yearly release cycle, you could set the upper limit to “this release plus a little of the next release” (50 (velocity) x 12 (sprints per year) x 1.5 (releases) 900 points. Now you have are target size of product backlog based on “what might actually be delivered”. For multiple teams on a single product, apply the same thinking.
How do we get to 900 points? You can start by looking at some large groups of potential attic candidates by establishing a criteria:
The really brave among you will set up a few of these criteria and simply apply it. After all, if we put things into the attic, its easy to get it back down from attic if we need to. What you'll mostly find is that when something important “comes back” again (and trust me, important items will come back) and you go up into the attic to find the relevant record, the attic item will not be quite the same thing and so you'll end up creating a new item that reflects current understanding.
After applying this kind of thinking you will probably find you still have too many items in the product backlog. The low hanging fruit is gone, so now you have have to go through the items individually and decide on disposal:
Once you have cleaned up your backlog, you now need to set things up so that you don't re-create the problem you had. Again, your approach will vary, but the base approach will come from the work you have done so far. Now that you have an upper limit on the number of items in the product backlog you can establish rules for accepting new items. For example you could say “new items can only be added to the product backlog if an existing item of equivalent size is removed from the backlog.” This approach can be applied to individual product backlog items, but also to groups or items in the case where we have a new “epic” requirement that is more important that items previously on the list. The approach will force a certain degree of “readiness” criteria for new items coming in. For example, it is hard to make this call if you don't have estimates on new items. Once again, when something is removed you will need to determine how you communication this to relevant stakeholders.
How you do all this and who is involved will depend on circumstances. The on-going triage after you have done the clean-up work will need to happen regularly otherwise you build up too many new items for consideration. When this happens I've seen teams simply ignore the build up leading straight back to the original problem, only now it will be harder to go through the initial clean up (“we tried this before and it didn't work …”). One approach is to do this kind of work during a product backlog grooming session but this is not the only way of achieving the result.
Once you have gone through all this, what will you have?
To me this seems like a worthwhile set of benefits over the traditional approach. And, after a period of time, you can delete all the items in the attic. This will happen when you realize that, in fact, no one has visited any of the items in the attic for a long time (just like the attic at home).