前言
项目不太可能一帆风顺的进行到验收，而是充满了变数，愿望是美好的，但现实是残酷的。所以这一次我想跟大家介绍一下如何团队如何面对失败的Sprint。
如何判定Sprint成败
Sprint的成败实际上没有泾渭分明的一条线，除非团队跟PO在做计划会议时就约定Sprint目标。
所谓Sprint目标就是PO确定的本Sprint最重要的任务项，没有完成目标，那么做多少其他工作也是枉然。
有了Sprint目标，成败在Sprint结束时就一清二楚了，实际上团队成员在Sprint没结束时就能确定Sprint会不会失败，要是每个团队成员都觉得Sprint已经完蛋了，那还是及早调整的好。
Sprint失败的诱因
接下来我们说说Sprint失败的常见诱因有哪些：
1.团队成员突发性调整
这个因素对于小团队几乎是致命的，如果是正常的5人团队，1人突然提出离职，1人被调到其他项目中，那么SM还是及早跟PO商量对策为好。
2.PO经验不足
这个因素也很常见，PO经验不足，在Sprint内进行大量的紧急需求的插入导致主要目标都无法完成，或是PO弄错了Sprint目标，导致给用户演示被一顿喷，从而导致失败。
3.技术债务爆发
有句话叫出来混早晚要还的，这类问题在对原有系统的升级中最为常见，本来预计3天完成的任务，结果搞到Sprint结束没有搞定，遗留系统往往牵一发而动全身，这改好了那又崩溃了。
4.不敢面对现实
这个也是十分常见的，在计划会议上明明已经发现了风险，很可能导致无法完成相应目标，但是碍于情面或过于乐观没有提出来调整目标，导致在Sprint结束时无法完成任务。
或是本来预计这个任务需要一个特殊的人投入5天，结果这个人常常被临时任务打断，在计划会议时没有考虑这个问题，或是心存侥幸，导致Sprint都被卡住挂掉。
本质原因：组织文化有问题，若组织文化良好，以上都不是问题，经验不足的PO根本不可能上位，人员调整也应该提前规划和商议，技术债务应该提早预估，应该按照股则来进行评估
如何处理
项目周期最后的回顾会议就是专门处理这个问题的。
最重要的是不要一味的追究是谁的责任。
如果Sprint失败了，那么回顾会议就十分重要了，但是不要直接就开回顾会议，要先收集资料和数据，这样在会议才能有迹可循。
让团队腾出一个大段时间来举行回顾会议，同时PO必须要参加。
以下是注意事项：
1.重点不是追究责任，而是分析更深层次的原因，然后改进
2.如果确实是团队成员的问题，那么必要的人事调整是必不可少的。
3.这种回顾会议时间一般少于2小时，要是开了10分钟大家都觉得没问题了，那么说明还有更大的问题隐藏着。
4.切忌含糊其辞，否则团队就变成大锅饭
5.一切以事实为依据，对事不对人，注意不能变成批斗会
6.改进要进行追踪和确认。
不要一味的追究是谁的责任