意外终止一个sprint

敏捷开发讲的就是适应变化。敏捷宣言的第二条原则明确指出“欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。”这就是为什么在scrum中PO负责维护产品backlog。PO对产品backlog条目的排序有最终发言权–包括从产品backlog中挑选一组条目作为一个sprint backlog,这也是PO适应变化的一种手段。
Sprint backlog是sprint要完成工作的预告表。团队基于速率提交合理的工作量,尽一切可能来交付他们承诺的东西。在sprint期间,PO或任何一个干系人都被要求去保持sprint backlog的稳定。团队通常也有这样的要求,以帮助他们以一个平稳的节奏交付产品增量。
但是,在意外情况下,当PO或团队意识到他们不能按照sprint目标进行交付时,sprint就不得不被取消或者终止。

Sprint意外终止的原因包括但不限于:
-公司改变了战略方向
-产品被市场淘汰
-技术上发生了的重大变化
-发现了更好的技术解决方案,当前sprint的工作作废
-重要紧急的外部变化使当前的sprint目标或大部分功能作废
-紧急bug修复或特性开发的要求,无法等到sprint自然结束

经常,在一个sprint进行过程中,PO或干系人会打断团队并订立新的sprint目标。很多时候,这个改变并不是因为一些紧急重要的因素,而是因为PO没有提前把事情想清楚。
假如sprint终止频繁发生,团队就不能有节奏地进行开发并产出高质量的产品增量了—而这恰恰是每个sprint的目标。
正式地取消一个sprint需要让干系人了解其引起的开销,比如终止一个进行中的sprint和重新召开sprint计划会议引起的企业成本。如果能确认在sprint进行中改变sprint backlog带来的好处要大于其带来的开销,那么,终止sprint是个不错的主意。

根据下面的要点进行实施:
-敏捷团队和PO确认sprint目标不能达成或者目标有了重大变更;终止sprint带来的好处大于其造成的开销
-PO要求终止sprint,并且知会到干系人
-如果有紧急情况出现(比如产品崩溃),敏捷团队需要抽身去应对。
-团队对sprint终止的原因进行分析,找出改进方法,如果可能的话,在下一个sprint就采取改进措施
除了极少数的情况,意外终止sprint其实也是一种提醒,尤其对于刚进行敏捷转型的团队。不能把每个新的求都当成紧急状况来看待。

原文链接:http://agileatlas.org/articles/item/abnormal-termination-of-a-sprint