产品待办事项列表（product backlog）是敏捷软件开发中用得较多的一项实践了。而在跟团队一起工作的过程中，我们发现虽然大家都在用Product Backlog，但是却没有完全发挥Product Backlog的最终作用。意启部落整理了一系列产品待办事项列表中的臭味，并给出了相应的建议。

好的产品待办事项列表（Product Backlog）应该具备下面的特性：

1. 排好序的(Ordered)

早期的Scrum手册中使用的词是优先级。对于不同的backlog是有优先级的（Prioritized）。随着经验的积累，人们发现，优先级并不能完全描述待办事项孰轻孰重。你或许还记得，上次团队问你，A和B，哪个要先做？脑子里浮现出客户A和客户B期待的表情，你回答：“同时进行吧“。同时进行意味着，你要同时聚焦在两件事情，甚至是多件事情上面。Scrum手册第二版出现后，把优先级换成顺序。A和B需要Pk出来一个唯一的顺序，这样，虽然根据团队的实际吞吐率，可以同时进行A和B，唯一的顺序让孰轻孰重变得更加明确。这样也有助于作为PO的你对需要解决的问题进行更深入的探索。

我们发现，在真实的开发团队中，很多用户故事具有相同优先级或者根本没有优先级的产品待办事项列表，这是

臭味一：无序（亦或是那个都重要）

2. 动态的（Dynamic）

产品设计本身也是一个对问题和解决方案探索的过程。在用户需要，技术可行，经济回报方面不断寻找平衡点。这个探索过程是动态的，是随着知识增加不断调整的。

而有的Product Owner会习惯性的全面考虑，希望把产品设计成一个大而完善的解决方案，于是他的Backlog有了臭味二：冗长

3. 细节适中(Detailed Appropriate)

如前面所说，好产品是一个探索的过程，正如夜间开车，既有目的地，也需要开车途中时时留意车前的状况，同时还需要经常注意远处路况；看不清近处或者只看远处都有潜在的安全隐患。

我们观察到产品设计中有类似的状况：即使是高优先级的用户故事都只是粗粒度的描述，也就是臭味三：近视眼。也有老板会敦促PO把产品待办事项列表（Product Backlog）整理到电子工具，方便出报表；或者PO在Backlog中关注于过多不重要的细节；于是导致了臭味四：远视眼

4. 有相应的估算(Estimated)

如何对项目的风险进行评估？团队在经历若干次迭代后其速率（Velocity）能保持在相对稳定的状态；速率同时也给PO对后续的迭代计划提供参考，同时是对风险进行评估的很好的参考数据。当团队里没有人关注风险，没有人关注速率时，就产生了臭味五：无估算（亦或是免费）。

产品待办事项列表的实践并不仅仅只是准备一个TODO-list这么简单，它应该是一个符合上述四条（简称ODDE）原则的。这些原则就像一面镜子，让你发现待办事项列表中的问题，然后去除臭。正如臭味的处方中提到的，它应该是由一系列的敏捷实践支撑的，这些实践是对敏捷价值观的实践。