敏捷实践之Sprint Backlog在看板中的移动

黄隽 Charlie

2019年04月

序  言

随着近些年敏捷在行业及企业的推广，越来越多的企业意识到了敏捷所带来的好处，并愿意在敏捷上有所投入，从而越来越多的朋友加入了敏捷从业者行列，愿意学习敏捷知识。多年热衷于敏捷的我，参与或主导大大小小敏捷转型项目实战和敏捷圈线上、线下活动，阅读大量书箱文献，活跃于敏捷大咖们的议题讨论事件，以及从事多年专职顾问的经验，有些小热情总结一系列文字内容帮来分享给那些已经或者正准备踏上敏捷之路的朋友们用于个人学习、研究和欣赏，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。

系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。

如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。

目  录

序  言    2

1     正常情况下的移动... 3

2     需求变更情况下的移动... 4

2.1      不接受变更. 4

2.2      拥抱变更. 4

1          正常情况下的移动

使用看板主要意图之一是控制在制品数量（WIP, work in process）,需要拉动式的移动，这样可以有效控制在制品数量，防止工作项过多积压。

另外需要提示一点，在整个移动过程的前提是需要制定一套移动规则，具体什么样的规则这里不做过多的描述，根据团队自身情况定义就好，规则根据团队意见可以调整几次，最后团队满意就是合适的。

2          需求变更情况下的移动

2.1       不接受变更

当一个Sprint的Sprint Backlog和Sprint 目标确认后，为了保持团队在很短的时间内，全力以赴的向着Sprint目标冲刺，一般情况下不接受PO提出的需求变更。在很短的周期内，PO是有责任负责整理好Sprint Backlog的，进一步说，PO至少应该整理好接下来1-3个Sprint需要做的Product Backlog，然后按优先级，挑选出最近一个Sprint的Product Backlog形成Sprint Backlog,因此经常性的需求变更建议团队不接受，另一方面也是一个好习惯的养成，促进PO对需求的把控能力。所以这种情况下，团队正常移动看板中的卡片就好。

2.2       拥抱变更

完成拒绝需求变更是不现实的，有的时候高优先级的需求一定要满足变更的要求。比如，有市场时效性的，本Sprint不能完成，不能抢占市场先机，但变更需要遵循“NO CHANGE”原则。接到需求变更后，首先不是直接接受或者拒绝，而是先对需求进行分析，分析对当前迭代的影响。一般分析结果为以下几种情况：

1)    无价值需求

与PO沟通协商，对于无价值需求果断拒绝，当然是与PO协商后的结论，看板中的卡片不做任何移动。至于这些无价值的需求怎么来的，情况比较多，这里不做引申了。

2)    变更少，影响小的需求

高优先级的，对Sprint影响小的需求变更，可以柔和接纳，但要评估工作量，做等价交换。简单说，就是把未做的优先级低的需求从看板中替换出来，移动到Product Backlog中，这也是Product Backlog Refinement的过程,然后看板中加入高优先级需求的卡片就好。如果是交换已经产生工作量的需求就需要分情况处理:一种是移回到Product Backlog列,这种情况多于以完成特性需求为目标，更符合敏捷。另外一种是移到Done列，这种情况多见于物理看板中对统计度量数据比较看中的团队，团队需要对工作量进行有效统计。当然第二种情况在有些电子看板中也可以灵活统计来满足团队需求，那么就可以直接移动到Product Backlog列。

3)    变更多，影响很大的需求

高优先级的，对Sprint影响很大的需求变更，需要停止当前Sprint，重新规划新Sprint。这里的影响很大情况是指当前Sprint中的需求可能再做下去也没有价值，这时果断停止当前Sprint，另外一种情况也可能是变更的需求本身确实需要很大的工作量才能完成，也需要停止当前迭代。这时根据最新的Sprint Backlog布置看板中的卡片就好。