敏捷游戏开发：冲刺与用户故事的应用
1. 冲刺回顾与结果跟踪
在敏捷开发的冲刺阶段，有一些关键的任务和决策需要关注。例如，对于“确保乔在提交动画之前进行测试”这一要求，由于这是日常工作，无需设为特定的行动项。而“当构建服务器构建失败时发送电子邮件”，若团队有程序员能实现此更改，他们可自行完成；若不能，则需生成行动项，将请求传达给维护构建服务器的团队。
冲刺回顾会议结束后，ScrumMaster会记录每个问题的答案，并在团队区域公布会议结果。在下次冲刺中，会勾选已完成的事项。上次回顾中未勾选的事项将在下次回顾时讨论，团队会决定是将其延续到下一个冲刺，还是从列表中移除。回顾有助于团队随着时间推移提高效率，忽视这一关键实践将无法实现敏捷开发的优势。
2. 冲刺失败的情况及应对
冲刺的目标是在固定时间内提升游戏的价值。然而，实际情况可能并不顺利，会出现各种导致冲刺失败的因素。
-冲刺中断：2007年秋季，圣地亚哥突发野火。起初火势看似遥远，作者决定去上班，但午餐后情况突变，工作室处于疏散区域。ScrumMaster仍关心周五的冲刺审查，这体现了其专业素养。幸运的是，工作室和员工未受严重影响，之后团队讨论是重启新冲刺还是完成当前冲刺，最终选择完成，且工作顺利推进，冲刺取得成功。
-冲刺重置：这是Scrum中较为极端的做法，允许团队或利益相关者宣布冲刺目标需要改变，或者团队无法在冲刺结束时完成目标。重置时，所有未完成的产品待办事项（PBIs）将返回产品待办事项列表，开发中的代码和资产将回退，团队和利益相关者回到冲刺规划阶段。冲刺重置成本高昂，应尽量避免，不过它能促使
