Sprint的陷阱
1. 在“真正的”Sprint开始之前使用永久的Sprint 0
2. 不断改变Sprint的节奏
3. 延长Sprint几天，以确保“完成”Sprint
4. 使用强化冲刺来捆绑在早期冲刺期间识别的松散末端
5. 在同一产品上与多个团队合作时，没有相同的Sprint节奏
Sprint规划的陷阱
1. 拥有一个没有Sprint目标的产品负责人
2. 使用不够精确的产品Backlog
3. 不知道开发团队的速度和即将到来的能力
4. 在制定Sprint计划时不考虑“完成定义”
5. 结束Sprint计划，没有对Sprint计划及其目标的共同承诺
每日Scrum的陷阱
1. 每天都没有做“每日”Scrum
2. 将每日Scrum视为Scrum Master的状态更新
3. 没有共享和清晰的Sprint目标作为主要指标
4. 专注于详细的活动，而不是团队取得的实际成果
5. 在每日Scrum期间不更新Sprint Backlog
Sprint评论的陷阱
1. 将Sprint Review仅作为演示考虑
2. 向产品负责人展示结果，而不是向利益相关者展示
3. 不邀请任何利益相关者，因此忽略收集有关增量，Sprint和产品Backlog的反馈
4. 取消Sprint评论因为“没有什么可以证明的”
5. 不要让开发团队参加Sprint评审，因为他们有更重要的事情要做
Sprint回顾的陷阱
1. 取消Sprint回顾，因为“没有改善”
2. 取消Sprint回顾，因为“我们没有足够的时间来改进”
3. 一遍又一遍地使用相同的格式
3. 结果导致了太多含糊不清的改进
5. 对即将到来的Sprint采用明确的方法计划没有任何改进的改进
积压细化的陷阱
1. 没有足够的Backlog改进，这导致低质量的产品Backlog有很多歧义
2. 做太多Backlog Refinement，导致产品Backlog过于详细
3. 将Backlog Refinement视为仅包含产品负责人和“Lead Developer”的活动
4. 考虑到积压改进太昂贵，不能花费10％的团队能力
5. 不涉及任何利益相关者澄清产品Backlog的特定部分
PS：我知道Backlog Refinement不是Scrum事件而是活动。但为了完整起见，将其添加到此文章中。
