是有序！不是按优先级排序！（转自：http://www.scrumcn.com/scrumptc/html/?336.html）

在过去，Scrum指南里面通常使用优先级来描述产品待办列表，或者写明产品待办列表是根据优先级来排序的。当产品待办列表必须是有序的时候，优先级排序是仅有而且难得的好办法。但最近，新的Scrum指南里面使用了有序(ordered)这个术语，而不是按优先级排序(prioritized)。这反映了很多在Scrum社区中的领导者长期以来的理解。让我们来看看改变的原因。

按优先级排序就是说根据各个项互相之间的重要程度之间的差异来进行排序。其中优先级驱动着两个在列表中的项目的比较。这很容易让人想起使用冒泡排序来进行对产品待办列表的排序：比较最顶端的两项，如果它们的顺序就是错的就交换它们，然后对接下来两项进行比较，然后重复这种操作直到所有项都到达了正确的位置上。排列优先级和排序之间的关系十分紧密。

在给产品代表列表排序时，Scrum团队和Product Owner会按照最大化投资回报率或者价值的目标进行排序。然而，很多人普遍认为投资回报率就是优先级。其实，投资回报率是对待办列表的长期投入和产出的结果，而并非简单地将待办列表中的各项的投资回报率相加。在某种程度上这是正确的，因为待办列表中的一项的投资回报率取决于其在待办列表中的位置。例如，假设有一个用户故事是要在网站的首页上显示一个会跳舞的圣诞老人。这个用户故事能够在十一月底到十二月期间带来一定的回报，但是如果是在七月或者是一月，回报就会大大减少了。当你改变用户故事在待办列表中的位置的时候，实际上你已经改变了它的投资回报率了，因为由于它的位置的改变，其发布的日期也会有所变化。

因此，产品待办列表必须要排序，顺序决定了产品待办列表中的项目的交付次序。团队可以就待办列表中的顺序和Product Owner进行讨论，但是当团队从中拿出用户故事的时候，必须先从最顶端的开始拿。其实，产品待办列表并不能保证其反映的一定就是其中各项的价值或者优先级。你不能因为某一项的投资回报率或者商业价值就直接给定其优先级，你必须要通盘地考虑待办列表中的所有项，才能够使得最终的投资回报率最大。

比如说，你要在热带里建一座房子，你要考虑到每天午后的大雨。你能够预见到一座房子必须有墙、窗户和门，但是屋顶才是你最关心的问题。然后，假如你要给你建造的房子建立一个产品待办列表，这时候很显然屋顶是最需要考虑到的，但是你真的会把建造屋顶放在第一位吗？这个就是要对代表列表进行排序来最大化长期投资回报率的时候了。这个过程需要对产品待办列表中的商业、市场以及工程学依赖关系都有清晰深刻的了解。这很明显是一个比单纯的冒泡排序要复杂得多的过程。

使用“排序”而非“排列优先级”就是为了要让Product Owner知道，他们必须要对用户故事的顺序做决定，而不是只是简单的说“这五个用户故事优先级是1，那三个优先级是2”。
Product Owner必须交付一个已经完成排序的产品待办列表。

当然，你完全可以使用优先级来作为排序的依据，因为“排列优先级”也是其中一种排序的方法。使用“优先级”来排序有可能会导致投资回报率的降低。Jeff Sutherland经常说，如果你的产品待办列表的顺序足够好的话，你甚至可以让你的投资回报率翻倍。当然，有些例外的情况，例如有时候你的团队需要给一些客户做一些固定成本的项目（详情请查阅Change for Free 和 Money for Nothing），这些只是一些特殊的情况，并不是对所有团队和公司都适用。Scrum指南也不提倡这种做法。总而言之，你不应该使用优先级来进行排序。

原文地址：http://www.scrumalliance.org/articles/367-its-ordered--not-prioritized