背景
一个人数为7人左右的团队采用Scrum框架工作。Sprint的长度，团队目前采用时间盒 为1周。团队经常会出现在Sprint结束时不能完成当初设定的Sprint目标，很多工作项 需要跨Sprint才可以完成。
问题分析
目前Sprint中存在的主要问题是Sprint目标完成不好，解决掉障碍，Sprint目标按承诺 完成即可。
团队成员的工作内容中包含很多探索性工作项，对工作内容领域不熟悉，需要投入一 些学习成本，导致工作项的实际完成用时要比正常多。每个用户故事的工作量也比较 大，多数超过24小时。PO对工作项完成标准的要求非常高，评审严格，不合格的工作 项在Sprint中经常返工。团队当前的Sprint时长为一周，并且四大事件按照Scrum框架 执行，其中Sprint计划会议和Sprint回顾会议平均持续时长为2小时左右。
从分析中归纳影响Sprint目标完成的几个主要因素如下表：
表3-3 影响 Sprint 目标因素表（一） 项用户故事下建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目标，可以试着把时间盒调为两周。同时要注意优化用 户故事的大小，提高四大事件的效率。
Sprint的时间盒由一周改为两周后影响因素会有所改善，具体如下表：
表3-4 影响 Sprint 目标因素表（二） 故事下建Task。Sprint的目标可以按Task级别 来平衡考量完成度。
4 PO完成标准高 时间相对宽裕后，理解PO完成标准更加充 分，在计划会议上明确验收标准（AC，
Acceptance Criteria） 和 (DoD，Definition of Done)。
5 Sprint周期短 调整周期后，团队成员氛围更加好，每个 Spring目标完成度得以改善，成员更加自信。
6 Sprint计划会议和Sprint回顾 会议持续时间略长
时间相对宽裕后，每项会议质量有所提高，
在合理的时间范围内可以高质量完成会议内 容。计划会议
其情况Sprint的时间盒长度建议如下，需要说明的是以下情况不是绝对的，需要根据团 队现况选择适合的就好，没有绝对的对与错，适合的就是最好的。
了解更多：时间盒
在Scrum框架中，工作在建议时间长度为一个月或者更短的迭代或循环中进行，这个 迭代或者循环叫做冲刺。冲刺在一个时间盒（Time Box）内，也就是冲刺有固定的开 始和结束时间。
● 时间盒的优点具体内容如下：
a. 时间盒是设定WIP数量限制的技术。WIP英文全称为work in process是已经开 始但还没有完成的工作清单。开发团队只开发自己认为在一个冲刺内可以开 始并按时完成的工作事项，因此时间盒是为每个冲刺设定WIP数量限制。
b. 时间盒可以强制排列优先级。我们需要先执行高优先级的工作，时间盒可以 以激发Scrum团队成员全力以赴按时完成冲刺内的工作。如果没有时间盒的 限制，Scrum团队成员就不会有完成工作的紧迫感存在。
f. 时间盒可以增强预测性。团队不预测后续长时间段内可以完成的工作，但是 预测下个冲刺内能够完成的工作是可以做到的。
● 每个冲刺持续期短有很多好处。持续期短的冲刺更容易规划，反馈快，错误有 限，投入产出比（ROI）高，有助于保持较高的参与热情，检查点多。具体好处如 下：
a. 持续期短的冲刺更容易规划。为短时间的工作范围做规划所需要的工作量比 给长时间的工作范围做规划的工作量要小得很多，结果更准确，可执行性更 强。
b. 持续期短的冲刺可以产生快速的反馈。快速反馈可以去掉不适宜的产品路径 和开发方法，避免产生更多的差产品质量成本（COPQ，Cost of Poor Quality）。最重要的是快速反馈可以使团队更快速地发现和利用稍纵即逝的 商机。 标。Scrum在每个冲刺结束时会有一个有意义的检查点（冲刺评审会议），
团队中的每个人可以根据展示的可以工作的特性做出判断和决策。有更多的
参考文献：Scrum指南（2017-Scrum-Guide-Chinese-Simplified），2017年11月版。 的根源在于如何管理好Backlog。再进一步理解，当有新的工 作项加进来时，如何更新Backlog，也就是我们常说的有了需 求变更（临时增加任务也算需求变更）怎么办？
敏捷方式是趋势，越来越多的开发团队开始接触和使用，DevCloud产品也是基于敏捷 思维设计的，以下内容均以敏捷方式叙述，包括但不限于Scrum框架。
● 对于场景一，可以从人员分工角度思考，建议开发团队人员最好有工作侧重点的 划分。一部分人员精力用于开发，另一部分人员侧重于应对突发工作。应对突发