Mary and Tom Poppendieck wrote in their new lean book "Leading Lean Software Development: The Results Are Not The Point " that if you have too a long list of user requests, limit it to the length that fits to your thoughput. And in their talk I heard one episode of their client where they accutally saw a list you would have to spend *years* to catch up, so they said to them "Discard the older part. you cannnot do with them anyway."

Discard the older part ? They are waiting for loooong time. I thought this idea was counter-intuitive. But I recalled Jim Coplien's pattern for telecommunication "call half queueing".(I don't remember the correct name of the pattern, but should be a reference somewhere) It says, if the waiting call list is very long, the next call to be connected is the newest call(the last arrived call), not the oldest call(first arrived call). This is the real-world implementation, and supported by psychology... a long waiting call can possibly be giving up.

More generally, the older part of the long request list has a good chance of being "stale".

If you think this is wrong, imagine you have a pile of unread newspaper. Do you read from the bottom of the pile or from the top ?
Or to be more upto-date, think about a long unread timeline of your twitter. Do you like to read the older part first ? I would start reading backward from the fresher tweets.

Any thoughts or comments ?

P.S.
As a product owner of astah*, UML and mindmapping editor, I'm thinking I should think more about priorities and how to notify the source of requests.... and else.