敏捷开发讲的就是适应变化。敏捷宣言的第二条原则明确指出“欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。”这就是为什么在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
