当你坐在一间教室里，正享受着敏捷培训课程（你总会不自觉地抽空查看那些不断出现的分布在众多列表中的超级紧急任务），这时你却突然听见教练嘴巴里蹦出了一些话，它听起来感觉似乎很完美同时却又那么疯狂…
这些话就是：产品backlog是一个有序列表，里面放着各种类型的待做任务（比如：特性，bug，需求调研等等）。
并且，它只包含：
– 一个最高优先级条目
– 一个优先级为2的条目
– 一个优先级为3的条目
– 其他类推
“什么？如果我们这样做的话，我们将会得到一个超过[800]（在这里插入你自己的一个大数字）个条目的backlog文档，而且对这么多的条目进行有效排序的可能性几乎为0.”
我时常听到这种担心，对于读了以上内容后产生相似担忧的那些同仁，我给出的建议可能有些不那么暖人心啊！因为处理这种巨无霸产品backlog时，你总是只有一个选择，那就是：宣告backlog破产！
怎么操作呢？
我们的PO拼凑出了大概像下面这样的一小段话（可能来自email，飞机空中放烟写成的文字，或者其他）
hi all,
我相信我们都清楚地意识到了维护那些各种各样无限增长的列表变得越来越难了。为此，我们不得不尽快把交付最高商业价值产品这事先搁置一下。
这些列表铺天盖地，分散人注意力，但坦白讲，里面许多条目是过期的和不再相关的。因此，我们要采取一些稍微激烈的措施来宣布产品backlog破产。
它们就是：
1.把所有列表中的所有条目都归档。不幸中的万幸，至少我们没把它们都给删了。
2.然后，我们把所有的需求，也可能是特性，bug，需求调研（或其他），都合并到一张列表中。这张列表我们称之为产品backlog。
3.毫无疑问，那些已归档的列表中会有些条目需要被“复活”–被添加进我们新的产品backlog中。所以，请让我知道这些条目。如果一个条目是一个特性或者需求调研，请弄清楚它和我们的产品版本号的对应关系。假如一个条目是某种缺陷，请写清楚它对我们已记录的bug的潜在影响。
4.为确保不再宣告backlog破产，这次我们将小量“贷款”，限制产品backlog的条目为[50](插入一个可控的大小)。一旦配额满了，我们只能移出一个旧的再加进新的，或者等待一个空位。
谢谢
真诚的PO
显而易见的好处
现在，这个方法有几个显而易见的好处。首先，你能保证backlog中的条目是当前适用的且有意义的。其次，你能确保所有“复活的”（新的）条目都通过了主要产品版本过滤。最后，你会发现这是个非常好管理的过程，作为新的（或“复活”的）条目，各种利益相关者需要花一定的时间来为其编写案例以便加入backlog，所以条目是慢慢的一条一条加入进来的。这将确保排序过程要优于一次处理所有的条目时的排序过程。
总结
人类是天生的囤积爱好者（你可以检查自己的电脑磁盘空间），这就是为什么我们经常会出现在backlog疯人院。不过，我们人类也确实感谢重新开始这一概念。产品backlog破产带给我们重新开始的稀有机会，同时也要认识到我们的老的列表被归档了（不是被销毁了），也要避免吓唬我们这些天生的囤积爱好者。
（Scrum中文网经授权翻译及转载，不得复制）
