迭代计划-华为云

需求管理 CODEARTS REQ-如何合理规划Sprint时间盒:解决措施

解决措施针对以上问题的分析，建议这种情景下将Sprint的时间盒由一周改为两周。Sprint的时间过短，团队成员会忙于准备计划会议、评审会议及回顾会议，真正完成工作项的时间较少。对于突发事件的应对能力减弱，不利于形成团队稳定的节奏。Sprint的时间过长，失去了短时间盒的优势，失去了时间盒的意义。因此，如果团队在时间盒为一周的Sprint中经常不能完成Sprint目标，可以试着把时间盒调为两周。同时要注意优化用户故事的大小，提高四大事件的效率。 Sprint的时间盒由一周改为两周后影响因素会有所改善，具体如表2所示。表2 影响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的时间盒长度建议如下，您可根据团队现况选择适合的时间盒。

需求管理 CODEARTS REQ 迭代计划

需求管理 CODEARTS REQ-如何合理规划Sprint时间盒:了解更多：时间盒

了解更多：时间盒在Scrum框架中，工作在建议时间长度为一个月或者更短的迭代或循环中进行，这个迭代或者循环叫做冲刺。冲刺在一个时间盒（Time Box）内，也就是冲刺有固定的开始和结束时间。时间盒的优点具体内容如下：时间盒是设定WIP（work in process）数量限制的技术。WIP是已经开始但还没有完成的工作清单。开发团队只开发自己认为在一个冲刺内可以开始并按时完成的工作事项，因此时间盒是为每个冲刺设定WIP数量限制。时间盒可以强制排列优先级。我们需要先执行高优先级的工作，时间盒可以强制我们按优先级排序执行小批量工作，这样我们的注意力可以更集中于快速完成高价值的工作。时间盒可以展示进度。时间盒可以展示团队需要多少个时间盒才能完成大特性的进度，帮助团队准确知道为交付整个特性还需要做多少工作。时间盒可以限定结束日期。每个冲刺中，时间盒限定了一个固定的结束日期，通过这种方式强制结束可能无休止的工作。时间盒可以促进结束。冲刺有明确的最后期限，这个期限不允许修改，这可以激发Scrum团队成员全力以赴按时完成冲刺内的工作。如果没有时间盒的限制，Scrum团队成员就不会有完成工作的紧迫感存在。时间盒可以增强预测性。团队可以不预测后续长时间段内可以完成的工作，但是预测下个冲刺内能够完成的工作是可以做到的。

需求管理 CODEARTS REQ 迭代计划

需求管理 CODEARTS REQ-如何合理规划Sprint时间盒:问题分析

问题分析目前Sprint中存在的主要问题是Sprint目标完成不好，解决障碍，Sprint目标按承诺完成即可。团队成员的工作内容中包含很多探索性工作项，对工作内容领域不熟悉，需要投入一些学习成本，导致工作项的实际完成用时要比正常多。每个用户故事的工作量也比较大，多数超过24小时。PO对工作项完成标准的要求非常高，评审严格，不合格的工作项在Sprint中经常返工。团队当前的Sprint时长为一周，并且四大事件按照Scrum框架执行，其中Sprint计划会议和Sprint回顾会议平均持续时长为2小时左右。从分析中归纳影响Sprint目标完成的几个主要因素如表1所示。

需求管理 CODEARTS REQ 迭代计划

需求管理 CODEARTS REQ-如何移动迭代中需求变更后看板中的任务卡片:需求变更情况下的移动

需求变更情况下的移动不接受变更当一个Sprint的Sprint Backlog和Sprint目标确认后，为了保持团队在很短的时间内，全力以赴的向着Sprint目标冲刺，一般情况下不接受PO提出的需求变更。在很短的周期内，PO是有责任负责整理好Sprint Backlog的，进一步说，PO至少应该整理好接下来1-3个Sprint需要做的Product Backlog，然后按优先级，挑选出最近一个Sprint的Product Backlog形成Sprint Backlog，因此经常性的需求变更建议团队不接受，另一方面也是一个好习惯的养成，促进PO对需求的把控能力。所以这种情况下，团队正常移动看板中的卡片就好。拥抱变更完全拒绝需求变更是不现实的，有的时候高优先级的需求一定要满足变更的要求。比如，有市场时效性的，本Sprint不能完成，不能抢占市场先机，但变更需要遵循“NO CHANGE”原则。接到需求变更后，首先不是直接接受或者拒绝，而是先对需求进行分析，分析对当前迭代的影响。一般分析结果为以下几种情况：无价值需求与PO沟通协商，对于无价值需求果断拒绝，看板中的卡片不做任何移动。至于这些无价值的需求怎么来的，情况比较多，这里不做讲解了。变更少，影响小的需求高优先级的，对Sprint影响小的需求变更，可以柔和接纳，但要评估工作量，做等价交换。简单说，就是把未做的优先级低的需求从看板中替换出来，移动到Product Backlog中，这也是Product Backlog Refinement的过程，然后看板中加入高优先级需求的卡片就好。如果是交换已经产生工作量的需求就需要分情况处理：一种是移回到Product Backlog列，这种情况多于以完成特性需求为目标，更符合敏捷。另外一种是移到Done列，这种情况多见于物理看板中对统计度量数据比较看中的团队，团队需要对工作量进行有效统计。第二种情况在有些电子看板中也可以灵活统计来满足团队需求，那么就可以直接移动到Product Backlog列。变更多，影响很大的需求高优先级的，对Sprint影响很大的需求变更，需要停止当前Sprint，重新规划新Sprint。这里的影响很大情况是指当前Sprint中的需求可能再做下去也没有价值，这时果断停止当前Sprint，另外一种情况也可能是变更的需求本身确实需要很大的工作量才能完成，也需要停止当前迭代。这时根据最新的Sprint Backlog布置看板中的卡片就好。

需求管理 CODEARTS REQ 迭代计划

云服务器内容精选

迭代计划

7*24

备案

专业服务

退订

建议反馈

售前咨询热线