如果我们没有给产品backlog大扫除以足够的重视，它就会变得比3年多都没修剪的灌木丛还要杂乱。今天这篇文章，我就跟大家分享一下PO在整理产品backlog列表时的4个小贴士。
小贴士1：
PO应该浏览整个backlog列表来找出要删除的部分。许多PO都有向backlog列表添加内容的习惯，但是却从不删掉那些不再需要的内容。如果一个特性不再需要了，它就应该被删除掉。 有些人会倾向于保留这些低优先级的内容，以便在未来什么时候再用上它们。如果你真的无法割舍它们，那么就想些法子把它们转移到其他地方吧。
假如你使用软件来管理产品backlog，软件中应该有删除功能。假如你用的是电子表格，那么把这些不需要的项从主表中剪切出来，粘贴到一个叫“长期产品backlog”的新表格中。我就是这样做的。而且，如果你像我一样的话，你把它们保存下来时感觉还挺不赖的，但它们基本上是不会再重见天日了。
小贴士2：
依然是关于避免产品backlog变大以至于失控的小贴士：为相关的待办项分组。我曾经碰到过一些PO试图管理超过2000项的列表。这也太多了。
我找到了一个合适的待办项的上限，就是在150到200之间。当一个产品backlog超过该上限时，它就会变得很难操作，基本上我们会很难理清各个待办项之间的关系；也很难记清是不是已经为某特性添加了待办项，于是又会加入一条新的，不知不觉间就加入了不少重复内容。
把相关代办项归到一组，称之为“主题”，这能让我们管理待办项时轻松不少。所以，我会把待办项进行分组。
小贴士3：
PO应该检查各个待办项的优先级。
代办项的优先级基于以下4个因素：
1. 特性的价值；
2. 实现该特性的学习成本；
3. 实现该特性将面对的风险；
4. 相对成本的变化。
小贴士4：
确认最高优先级的待办项能马上投入工作。每个最高优先级的待办项都应该被深思熟虑过，并能够在下一个sprint中投入工作，然后在正常情况下能够完成。
这并不是说每个待办项都要被完完全全地了解得非常透彻；而是说，一旦进行中的代办项出现了问题，团队和PO能在sprint中将其很快解决掉。
假如交付一个最高优先级的待办项需要召开3次“利益干系人指导委员会”，那么把它定位在最高优先级就是不明智的。
以上，就是产品backlog大扫除的4个小贴士。即使说它是大扫除，那也比车库大扫除要难得多啊。
原文作者： Mike Cohn
译者：Scrum中文网
原文出处：http://www.mountaingoatsoftware.com/blog/4-tips-for-spring-cleaning-your-product-backlog
