【华为云技术分享】敏捷实践：一周的Sprint太短，可以调吗

背景

一个人数为7人左右的团队采用Scrum框架工作。Sprint的长度，团队目前采用时间盒为1周。团队经常会出现在Sprint结束时不能完成当初设定的Sprint目标，很多工作项需要跨Sprint才可以完成。

问题分析

目前Sprint中存在的主要问题是Sprint目标完成不好，解决掉障碍，Sprint目标按承诺完成即可。

团队成员的工作内容中包含很多探索性工作项，对工作内容领域不熟悉，需要投入一些学习成本，导致工作项的实际完成用时要比正常多。每个用户故事的工作量也比较大，多数超过24小时。PO对工作项完成标准的要求非常高，评审严格，不合格的工作项在Sprint中经常返工。团队当前的Sprint时长为一周，并且四大事件按照Scrum框架执行，其中Sprint计划会议和Sprint回顾会议平均持续时长为2小时左右。

从分析中归纳影响Sprint目标完成的几个主要因素如下表：影响Sprint目标因素表（一）。

影响Sprint目标因素表（一）

序号	影响因素	具体分析
1	探索性工作项多	无法改变现状，学习成本的投入是必须项。可以考虑团队成员间知识共享，随着能力提升学习成本会逐渐减少。
2	工作领域不熟悉，需要学习成本	无法改变现状，学习成本的投入是必须项。可以考虑团队成员间知识共享，随着能力提升学习成本会逐渐减少。
3	用户故事比较大	由于工作项的特殊性，用户故事普遍比较大，可以考虑拆分为更小的故事，或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量完成度。
4	PO完成标准高	进一步理解PO完成标准，在计划会议上需要明确验收标准（AC, Acceptance Criteria）和 (DoD, Definition of Done).
5	Sprint周期短	团队初始确定的周期长度为一周，经过几轮Sprint后，如果Sprint目标完成不理想，根据工作项特殊性考虑到周期有点短，适当调整周期。
6	Sprint计划会议和Sprint回顾会议持续时间略长	每项会议其实是有建议的时长，正常一个月的Sprint周期，建议Sprint计划会议为8小时，那么按比例一周的Sprint，建议计划会议为2小时时长。同样，一个月的Sprint周期，建议Sprint回顾会议不超过3小，显然，对于一周Sprint时长的回顾会议用掉2小时是严重超时的。

解决措施

针对以上问题的分析，建议这种情景下将Sprint的时间盒由一周改为两周。Sprint的时间过短，团队成员会忙于准备计划会议、评审会议及回顾会议，真正完成工作项的时间较少。对于突发事件的应对能力减弱，不利于形成团队稳定的节奏。Sprint的时间过长，失去了短时间盒的优势，失去了时间盒的意义。因此，如果团队在时间盒为一周的Sprint中经常不能完成Sprint目标，可以试着把时间盒调为两周。同时要注意优化用户故事的大小，提高四大事件的效率。

Spring的时间盒由一周改为两周后影响因素会有所改善，具体如表：影响Sprint目标因素表（二）

影响Sprint目标因素表（二）

序号	影响因素	Sprint由一周改为两周后的相应缓解
1	探索性工作项多	有相对充分的缓冲时间应对学习、探求性工作以及突发情况。
2	工作领域不熟悉，需要学习成本	有相对充分的缓冲时间应对学习、探求性工作以及突发情况。
3	用户故事比较大	时间相对宽裕后，计划会议开得更充分，用户故事拆分为更小的故事，或者在每项用户故事下建Task。Sprint的目标可以按Task级别来平衡考量完成度。
4	PO完成标准高	时间相对宽裕后，理解PO完成标准更加充分，在计划会议上明确验收标准（AC, Acceptance Criteria）和 (DoD, Definition of Done).
5	Sprint周期短	调整周期后，团队成员氛围更加好，每个Spring目标完成度得以改善，成员更加自信。
6	Sprint计划会议和Sprint回顾会议持续时间略长	时间相对宽裕后，每项会议质量有所提高，在合理的时间范围内可以高质量完成会议内容。计划会议

其它情况Sprint的时间盒长度建议如下，需要说明的是以下情况不是绝对的，需要根据团队现况选择适合的就好，没有绝对的对与错，适合的就是最好的。

·一周到两周

新产品研发团队，产品具有时效性的特点，业务需求迎合市场随时调整，灵活多便，快速响应业务需求，经常性的自检。

·两周

团队节奏相对稳定，故事点较大，不好拆分，需要更多的时间评审和返工修正。

·三周到四周

节奏稳定，团队稳定，需求稳定，团队有固定的节奏，浪费较少。

了解更多：

什么是时间盒？在Scrum框架中，工作在建议时间长度为一个月或者更短的迭代或循环中进行，这个迭代或者循环叫做冲刺。冲刺在一个时间盒（Time Box）内，也就是冲刺有固定的开始和结束时间。时间盒的优点具体内容如下：

1）时间盒是设定WIP数量限制的技术。WIP英文全称为work in process是已经开始但还没有完成的工作清单。开发团队只开发自己认为在一个冲刺内可以开始并按时完成的工作事项，因此时间盒是为每个冲刺设定WIP数量限制。

2）时间盒可以强制排列优先级。我们需要先执行高优先级的工作，时间盒可以强制我们按优先级排序执行小批量工作，这样我们的注意力可以更集中于快速完成高价值的工作。

3）时间盒可以展示进度。时间盒可以展示我们需要多少个时间盒才能完成大特性的进度，帮助准确知道为交付整个特性还需要做多少工作。

4）时间盒可以避免不必要的完美主义。有时候团队会花过多的时间把事情做得“完美”。每个冲刺中，时间盒限定了一个固定的结束日期，通过这种方式强制结束可能无休止的工作。

5）时间盒可以促进结束。冲刺有明确的最后期限，这个期限不允许修改，这可以激发Scrum团队成员全力以赴按时完成冲刺内的工作。如果没有时间盒的限制，Scrum团队成员就不会有完成工作的紧迫感存在。

6）时间盒可以增强预测性。团队不预测后续长时间段内可以完成的工作，但是预测下个冲刺内能够完成的工作是可以做到的。

每个冲刺持续期短有很多好处。持续期短的冲刺更容易规划，反馈快，错误有限，投入产出比（ROI）高，有助于保持较高的参与热情，检查点多。具体好处如下：

1）持续期短的冲刺更容易规划。为短时间的工作范围做规划所需要的工作量比给长时间的工作范围做规划的工作量要小得很多，结果更准确，可执行性更强。

2）持续期短的冲刺可以产生快速的反馈。快速反馈可以去掉不适宜的产品路径和开发方法，避免产生更多的差产品质量成本（COPQ,Cost of Poor Quality）。最重要的是快速反馈可以使团队更快速地发现和利用稍纵即逝的商机。

3）持续期短的冲刺投入产出比（ROI）更高。持续期短可以更早、更频繁地交付，有更多的机会快速投入生产，产生收入。

4）持续期短的冲刺所犯的错误也是有限的。在短短1或2周的时间内，就算错了，全部搞砸了，也只是失去了短短的1或2周的时间，不会带来巨大的损失。坚持持续期短的冲刺能够进行频繁地试错，协调和反馈。

5）持续期短的冲刺有助于保持较高的参与热情。团队参与工作的热情，兴趣和兴奋程度会随着时间的拉长而越来越弱。如果一个项目时间过于长，人们看不到结果，那么显然人们会逐渐失去兴趣。持续期短的冲刺通过频繁快速的交付可用的工作产品，让参与者有满足感，操持较高的参与热情，便团队成员恢复兴趣并渴望继续完成冲刺的目标。

6）持续期短的冲刺能提供多个有意义的检查点。传统瀑布式开发有里程碑，例如分析、设计、编码、测试和运行。这些里程碑其实是一些不太靠谱的指标。Scrum在每个冲刺结束时会有一个有意义的检查点（冲刺评审会议），团队中的每个人可以根据展示的可以工作的特性做出判断和决策。有更多的检查点来检验和修正，我们就能更好地应对复杂的项目。

参考文献

1. Scrum指南（2017-Scrum-Guide-Chinese-Simplified），2017年11月版。

作者：黄药师（黄隽）