定义：

• Scrum顶目周期以一组迭代周期“Sprints”组成可以和极限开发的迭代周期类比
• 典型的迭代周期为2~4周或者最多一个自然月。冲刺一旦开始，持续时间是固定，不能被拉长或缩短
• 一个冲刺结束，下一个冲刺立即开始
• 一个固定的周期
• 产品的设计，开发，测试全部都在一个迭代内完成
• 迭代一旦开始，时间盒就不能再拉长或缩短，不能延长时间，也不能缩短时间
• 迭代的结束以时间盒长度为准，而不以工作量来决定，可增加工作量，可删除。

如何决定周期的时长？如何保持稳定

• 一个迭代/冲刺周期的长短的设定，是1周、3周，或一个月，这取决于能够保障多长时间需求变化不影响到产品开发。
• 迭代/冲刺的长度限制在一个月内。当迭代/冲刺的长度太长的话，对要构建什么的定义就有可能会改变，复杂性也有可能会增加，风险也有可能会增加。 同时不利于自检
• 不确定性越高，迭代可以短一些
• 更多的迭代次数意味可获得更多反馈，如果10周的一个发布版本，那么建议迭代的时间盒设置：2周，共5个迭代

不允许变更

• 禁止变更交付成果和交付日期
• 一旦团队作出承诺，就不允许变更交付件，包括有损质量的变更
• 如果发生重大变化，PO有权可以中止当次迭代（必须记住！）

• 在迭代中会出现“分解”和“澄清”，但是不允许添加新工作，或者对现有工作进行“实质变更”

  变更 Vs 澄清

• 如果存在争议，那么将其认定为变更，放到PB中，下一次迭代再考虑。

• 澄清、细化用户故事，可以允许
• 但是变更，从A变到B，那就不允许了
• 但是，实操层面，PO是拥有最终生杀大权，他有权叫停需求，替换需求

关于取消Sprint

• 如果Sprint目标过时，那么Sprint就会被取消。比如公司的发展方向或者市场上或技术上的状况发生改变，这些变化都可能导致Sprint被取消。总的来说，如果某个Sprint对其所在环境来说失去了价值和意义，那么它就应该被取消。