The problem with a backlog (as I see it) is that a backlog tends to keep different organizations from having an honest discussion about what the capacity (velocity) of the development organization shows is possible vs. what the requesting organization wants done.  If you don’t engage in a dialog, then expectations are not aligned, transparency is compromised, and distrust can arise between organizations.  Thus I recommend that a LIMITED backlog equivalent to a couple or three cycles of work is adequate for making sure there is always something to do and it is the current highest priority work.  One way to discover the appropriate length of this queue is to relentlessly remove the work that has an age older than the average age of work that is getting through the queue.  Those items have fallen to the bottom of the queue and will very likely never get done.  Another way to discover how short a queue can be is to keep on shortening it relentlessly until it is clear that it can’t be any shorter.  Remember, the length of a queue is the primary determinant of how long it takes work to get through your system, unless you have a dead space at the bottom of the queue – in which case – why bother to have that work in the queue in the first place?

The limited queue approach works in a maintenance and request-based world, but in a product development world, the objective in is different, so the work queue will operate a bit differently.  In product development, there will be a product roadmap which lays out the general capabilities the product must have along a timeline (roughly equivalent to a release plan).  The game in this environment is to TIMEBOX  rather than to SCOPEBOX capabilities – thus a milestone-based release plan drives the work queue.  The idea is to flesh out the details of each timeboxed delivery as close to the delivery milestone as possible, to ALWAYS meet the delivery date / milestone / timebox, and not to engage too heavily in wishful thinking about what scope can fit into each timebox.  The way to determine here if your backlog has gotten too long or too detailed too soon is to determine what % of so-called “requirements” are changed from the time they are specified until the system is implemented. This is often called requirements “churn”.  If this churn is greater than – say – 10%, then the detailed specifications are being done too soon.