From a thread in [leanagilescrum]:
Everything that you KNOW (or are reasonably certain of) about the future can be in the backlog. It gets to be waste when you put in the backlog stuff that has a high likelihood of changing. So the trick is to put in all of those things in the future that are going to happen – trade show, product launch, etc. And put in what you know for sure about what the software will have to do by those deadlines. What I’m proposing that you avoid wishful thinking and guessing in the backlog – only put in what is reasonably unlikely to change.
If you measure the churn (change to backlog items from the time they are entered until the product goes into production), I would say that 10—15% churn is not a problem. But 50-200% churn means someone is wasting a lot of time putting stuff in the backlog that is going to change – they do not have much of a sense of what is certain and what is not. High churn is often a sign the backlog is used to try to deter change and insulate the organization from uncertainty, rather than creating a process that is good at responding to events as they unfold and allowing the organization to deal with uncertainly.
I suggest that you draw the line on putting items in the backlog at the point where you have a reasonable degree of certainty that backlog items won’t change and will get done. You can draw this line for the number of items in the backlog and also for the detail of each item in the backlog. To do this, you measure backlog churn plus the percent of items that are unlikely to get done. If this number is over 20% - 25%, then your process is creating too many backlog items and/or too much detail too soon.
Mary Poppendieck
Author of: Lean Software Development & Implementing Lean Software Development
