译者语：传统的项目管理模式使用甘特图来制定工作计划，在Scrum模式下，我们用Sprint待办列表来表示工作计划。排序是Sprint待办列表的核心，怎样维持工作的节奏？如何有效率地完成交付？还有如何平衡PO的影响等等，这些都是排序时要思考的问题。Scrum追求开发团队自我组织，但实际上要实现这一点不是一件容易的事，正如文中所言，能独立地安排工作计划，是团队实现自组织前的重要一步。因此，每一个Scrum开发团队都应该认真面对工作计划。
每天，开发人员在一起决定工作项的顺序。
开发团队会根据团队速率和从产品待办列表的顶部拖入到Sprint的工作项的价值，来创建一个工作计划——Sprint待办列表。从进入开发阶段起，就要开始寻求如何有节奏地进行增量开发，或是通过最佳的工作计划整理最大限度地保持住昨天的势头。
仅当开发团队在当前Sprint后期预报了Sprint的目标时， Scrum要求对特定目标做出承诺的态度是十分肯定的。而且一般来说，健全的Scrum团队能够满足他们对Sprint待办列表交付的预期。团队通常会提前发布两到三个Sprint的计划 ，不过目前只有当下这个Sprint是需要交付的。当然，有时候计划难免会被紧急需求打乱，即便如此，运转良好的Scrum团队仍然可以做到稳步地兑现交付计划，以确保对业务提供支持。
Sprint的控制权其实应掌握在Scrum团队自己手里，不过Scrum从业者们有时难以真正领会这个游戏精神。特别是当 Scrum 团队执着于利益相关方的期望和团队的承诺时，会很容易忘记他们所享有的自主权。团队从Sprint一启动，就致力于实现 Sprint目标。也有Scrum团队认为应该按照产品代办列表项（PIBs）的排列顺序安排工作计划。但是这样一来，即便有些待办列表里的任务没有在Sprint 结束时完成，团队会觉得没有问题，因为至少他们完成了列表中最重要的任务。问题是开发团队会因此而开始自满：失去了让Sprint待办列表清零的动力。然后会导致这样的结果“我们承诺，但是......” 这就剥夺了团队对“预测”这个词的应负有承诺的态度，也使PO对自己面对市场的管理承诺的能力产生了一些不安全感。
提前给出最佳的Sprint代办列表排序是个挑战。如果有5个PBI，每个PBI又包含9条SBI，则会出现45的阶乘种排列组合（2*10的56次方）！并且在sprint进程中插入紧急需求，也会令列表项出现增减。有的排序方式的确能加快开发速度，但有的也会拖慢速度，而且排序每天都会变化。Scrum的精髓就是帮助团队找出那个速度最快的排列，这也是每日Scrum的意义之所在。
PO不会告诉团队如何兑现承诺， Ken Schwaber曾引用 野中郁次郎 ( 创新求胜: 日本企业如何创造创新 [NT95], p.85) 的话："团队在Sprint期间有充分的自主权。"产品待办列表的顺序反映了 PO的意愿，尽管PO可以决定PBI的最终顺序，但是他们决定不了开发团队如何组织工作。假如开发团队谨遵PBI 排序制定工作计划，就会导致PO和开发团队之间的防火墙出现泄漏，使得PO被默许可以支配或者打断开发团队的工作。
如果开发团队的工作计划跟从PBI的排序，那么一旦市场需求的优先级在Sprint期间发生变化，PO就可以要求改变交付的顺序，这意味着是PO在支配开发团队。在这种情况下，如果开发团队完不成Sprint目标，就很容易指责PO的干预，这就让人很难相信这类情况在今后的Sprint中不会发生。结果就是开发团队的积极性被削弱，不再对Sprint事事关心了。
不成熟、不完美的跨职能开发团队，往往会过多受制于这种强制性的工作计划。例如当开发团队中负责数据库开发的人很少，但 PBI 里优先级最高的项目却需要大量的数据库开发，并且团队又在使用单件流的工作模式（25节）时，团队只能是无能为力，无法利用现有的技能推进其他的PBI。另一方面，开发成员是可以在主技能之外找到新的学习和工作机会的，长远地看，这样调整工作计划可以提升多技能团队的敏捷性。
当障碍出现并阻塞了Sprint时，它会拉低团队在Sprint里交付的价值。因此让开发进程在障碍出现时也能保持顺畅是非常重要的，尽管制定工作计划时无法预见到这些障碍。此外，开发团队之外的人也不知道该如何从大量的选项中找出那个能解除障碍、维持价值最大化的办法。
开发团队给PO预告了整个Sprint待办列表的交付。Sprint待办列表通常表示一个市场交付单元，也就是说从市场层面看，PO需要把Sprint待办列表当作是一个最小的、可销售的功能：常规产品增量。PO可以根据开发团队的开发计划来制定软性的市场计划。但若是开发团队正致力于完成所有项目， 而这时PO却要他们先搞定那几个最重要的再说，开发团队的士气肯定会备受打击。紧急需求很可能导致的结果就是开发团队有时完不成整个Sprint。或许从不完整的交付中团队也能学到些什么，但是强迫团队的做法很不明智，哪怕强加的是最佳的工作排序，因为这样做的代价是让团队失去自组织性，从而失去了优化交付长期价值的机会。
因此，要让团队成员自己决定那个能让他们完成Sprint列表和交付目标的最佳的工作顺序。开发团队依照某种顺序自组织地开展工作，他们认为这样花费的成本或者时间才是最少的，或者说产生的价值最高。用产品待办列表的排序来告知团队，而不是驱使他们服从决定。开发团队也可以通过主动创建任务排序来回应紧急需求，而不是被动地接受来自外部的随意安排。当任务的颗粒度越细时，分组内（第一是按Sprint分组，二是按PBI分组）排序的限制也就会越少。
开发团队可基于灵活性和集体智慧制定出一个有序的工作计划，用以开发产品增量，最大限度地为业务目标提供支持（体现在Sprint目标里）。开发团队每天都要审视这个工作计划，并通过不断更新这个计划来回应团队的进度、变化中的市场环境、Sprint目标以及其他一切开发团队可以接受的意见。关于自主的团队：如果有人告诉团队该怎么做事情，这还能算是自组织吗？那这就是ScrumMater 的工作了，去激励团队做到自组织的水平。
和预测天气类似，团队只是预估而不是承诺在Sprint期间可完成的工作量。预估是部分基于团队最近的表现 （见66 昨天的天气，点击阅读：【Scrum模式语言2】昨日的天气）。进一步讲，工作计划并非静态的，开发团队在每日Scrum会上都会去更新它。
如果开发团队能自己创建工作计划，就能更好地实现自组织，摆脱PO的过度影响。开发团队可以根据自己的开发、组织能力，不受干扰地安排任务顺序，这对于受够了微观管理的团队而言是一种解放，不过同时也要求团队对工作计划具有责任感、纪律性和主人翁精神。要培养出这种责任感和主人翁精神，团队需要保持专注和 经常从ScrumMaster的指导中获益，尤其是当团队正处于从微管理模式向自治模式转型的阶段。
当然，由PBI之间可预见的工程依赖性决定的任何产品待办事项顺序也将表现为工作计划项目之间的依赖性。开发团队可以合理利用这点，制定出符合其技术特性的工作计划。过于随意的工作计划会导致Sprint结束时出现大量的半成品PBI，使用 Swarming：单件连续流，就可以解决这个问题。
有的Scrum遵循传统的"事有先后"的原则，开发团队有责任按照产品待办列表上顺序进行交付。这样做的理由是团队不必浪费时间讨论顺序问题，并且也是出于对 PO意愿的最大尊重。而我们认为这是PO控制团队的一种间接手段，会影响团队的自组织能力。类似这样的外部干预，反而很可能降低团队速率，因为团队原本是可以通过复盘工作计划来优化团队速率的。
开发团队应该努力在Sprint中期解决任务项之间依赖关系。如果PO觉得团队无法控制工作程序会从而导致关键的PBI面临风险，那他们可以通过Sprint目标或者通过战略性地调整Sprint长度的方式来降低风险。
考虑这样一种情况，有时为了迅速应对市场出现的意外情况，需要在当前Sprint立即交付一个PBI。PO可以重排交付的顺序，但仅仅是为了让这个异常情况更显眼，以及把问题推入紧急处理流程。只有在成熟且最富有经验的 SCRUM 团队中才有可能接受和PO就工作计划的顺序进行协商，但前提是必须征得开发团队的同意。
Jeff Sutherland 在《SCRUM 手册》 [Sut10] (pp. 23–24) 中写道："团队通过对 Sprint待办列表里的任务进行排序，使生产速率和‘已完成’功能的质量得以最大化。”
——译者：Wang Yang
校对：Leo Yan
参考资料：
（1）A Scrum Book：76 Developer-Ordered Work Plan
