传统上，有些产品负责人（product owner）通过对项目经济回报指标孤立地两两比较，进行 backlog 优先级排序。成功的敏捷团队通常采用一种整体的方法，综合考虑 backlog 条目的风险、依赖关系和复杂性的相互影响。
James O. Coplien 2011 年 8 月 3 日在Scrum Alliance 网站上发表了一篇文章，仍在引发评论，文中称新版Scrum 指南中的改变与产品backlog 优先级相关，或者按照James 解释的一样，排序。
对一个列表进行优先级排序意味着按照各个项目的相对重要性排序。优先级排序促使两两比较列表中的项目（根据字典中的定义）。考虑一下采用冒泡法来对产品backlog 进行优先级排序：比较最上面的两个项目，如果顺序错了就交换，然后再移向下一组项目，就这样不断循环直到列表中的每个条目都排好顺序。优先级排序和排序就这样相似。所有的比较都是局部的。这个过程类似于局部优化。
更广义的说，Scrum 团队和产品负责人（Product Owner）在排列PBI 时特别需要考虑整个backlog，以便得到最优的价值或ROI。大多数人通常将ROI 当做优先级，然而要将ROI 认为是全部backlog 排序后的长期结果，而非仅仅是将每个条目的ROI 加总。这种观点部分是正确的，因为每个单独条目的ROI 依赖于它在backlog 中的位置。
Arlen Bankston ，一位敏捷教练和咨询师，进一步解释了需要长远的看待每个项目直接 ROI 贡献。
每个单独用户故事的价值——特别是在新产品开发早期——通常因为较早得到市场和客户对功能的反馈而获得更多价值，而不仅仅是直接的 ROI 贡献。这就让简单的两两比较每个单独的用户故事成为一种过于狭隘的方法，因为产品的整体模式和客户探索必须要考虑进产生的收益。
敏捷社区的其他人使用了很长一段时间与排序有关的变量。几年以前，在一次谈话中， Roland Cuellar 提出了一个更好的术语，叫投放市场顺序（sequence to market），这个顺序结合了业务、技术和其它因素，比如风险和依赖关系。采用“顺序”这个词很有帮助，因为它允许产品管理不再困扰于“所有都是高优先级”，可以这么说：不错，这可能是事实，但是让我们决定一下下次发布哪个高优先级的项目。
因此，无论它被称为排序，优先级排序或顺序，有效的产品负责人从整体的角度看待他们的 backlog，以保证每个项目按正确的次序交付以获得最高的直接和长期价值。
你在这方面有什么经验呢？
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论