How Do We Deal With Product Backlog Explosion?

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:

• You will waste time every time you go back and re-visit this list of requirements and this will happen at least once every planning session. This is the same as having 600 items in your email inbox and having 5. If you have 600 you will spend time working, worrying those 600 even if you don't think you do. (If you don't believe me, work to halve your inbox and see how much better it is).
• There is a high probability that something that “did not make the cut” this time will also “not make the cut” next time. The business has moved on and there are always high priority items coming in.
• You will lose touch with all these requirements. Having a huge list means its hard to keep everything in mind and so more difficult to focus on what is important.
• There is an overhead associated with large lists. Every time something needs to be done, you are now positioning in a huge list so there it takes longer to do simple things. And if you have huge lists you need something to categorize them into meaningful groups so its easier to think about them, and so there is overhead in terms of setting up and maintaining a management system associated with this.
• There is no relationship between being “on the list” and “having a chance to actually get done”. We may feel better telling customers that “it is on the list”. It may be easier to communicate with stakeholders that it is “on the list”, but the reality is that only those at the top of the list have any chance of actually being worked. What is sad is that I suspect that people who hear “its on the list” understand that it really means “you aren't going to get it”, but we still maintain the fantasy anyway.
• In one way this list represents a list of “work in progress”. What we know from queuing theory (Little's Law in particular) is that if you have a big batch, then you can increase throughput by reducing the size of the queue.
• Clarity is lost for anyone looking at the list. Because there are special labels, meaning associated with fields as we try to manage all this data, anyone coming in to the list who does not have these special encoding in mind will form an incorrect or incomplete understanding of what the list means.

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 Acceptance Criteria (or 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.

Now while this might sound a little aggressive, my recommendation is that you start by putting everything in the attic, and then only bring those into the product backlog on a case by case basis, perhaps even as you actually work an item. This works because generally people are better at selecting what gets started than deciding (and enforcing) what stops. Make sure you establish a limit on the amount of work you have in progress (WIP limit) to encourage flow of value.

Often you are not able to do this, perhaps for political reasons, or because there is a contract driving work, or you don’t feel like the organization has the discipline, etc.

For these situations you need to understand how much you will likely be able to deliver over a period of time so you can 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 (or throughput, whatever you are comfortable with) 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:

• Have a look at your product road-map. Are there things in the product backlog that are not related to your road-map? If yes, then think about putting these into the attic.
• Put the bottom half of your backlog in the attic. Trust me, even without looking at your backlog, unless you are already doing aggressive triage on the backlog, there is a bunch of stuff that you should never revisit. My assumption is that these are already toward the bottom since most people work actively on the top of the backlog. So put them in the attic.
• Set an “age” criteria. For example, “if the item was created more than 2 years ago” or “last viewed more than 1.5 years ago” then put them in the attic. The thinking here is that if its been there for a long time and we haven't done anything about it then it is unlikely this will change in the future.
• Set a “completeness” criteria. For example, “must be in use story format, have Acceptance Criteria (or Conditions of Satisfaction), have “investment allocation” filled in and have an estimate”. The thinking here is that if the backlog item is not a good item, then the team won't work on it any way. This has the side effect of getting your important product backlog items “complete” as part of the process.
• Set a “type” criteria. For example, “we will only work 20% of capacity on defects” and use this formation to weed out long lists of specific types. The thinking here is similar to setting the upper limit in the first place.
• Set a “priority” or “value” criteria. For example, “we will not work any P4 / low priority items reported internally”. The thinking here is that it is of little importance, we aren't going to do anything about it.
• Or combinations of the above, or other criteria you have.

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:

• Go through each of the items on in your product backlog. Ask yourself how the item fits into the vision and goals you have established for the product (you do have release goals, right?). If it doesn't fit in perhaps it is a candidate for the attic.
• Rigorously order the product backlog. Many people explain to me their product backlog is not ordered (or to apply old term, prioritize). While there are a number of reasons for this, if your product backlog is not ordered per what you think is important, it is still ordered in some way, and you are missing an important tool to get the best out of your team. If the order is really not important then it won't matter if we put a line the cumulative points in the backlog sum to 900 and kill anything lower than that. Most people would balk at this approach which implies there really is an order. Get your backlog ordered so you can make these kinds of calls.

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?

• A product backlog that actually has a chance of being delivered
• A simpler backlog of important items that by comparison are easier to track mentally
• A process for on-going triage aimed at keeping the product backlog healthy
• A set of product backlog items that are ready for use by the team and that has had good discussion with the team
• The potential for more realistic communication with stakeholders (its up to you whether you take this potential)
• Less wastage as we make calls early on what does not get done, and so do not apply further effort to it
• Increased clarity as there is less need for special understanding of the product backlog

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).