迭代计划与松弛时间管理
1. 迭代周期选择
不同的迭代周期对团队有着不同的影响：
-一周迭代：给团队带来较大压力，使得充满活力的工作更难开展，还可能限制重构。速度稳定性较差，因为一个假期就可能对迭代造成很大的时间损失。不过，对于新团队较为适用。
-两周迭代：压力稍小，能带来更稳定的速度，适合熟悉极限编程（XP）实践的成熟团队。
-三到四周迭代：周期太长，不能给团队或更大的组织提供足够的反馈。若认为长迭代对团队有用，可以尝试，但要注意长迭代对错误更敏感，发现和纠正错误所需的时间更长。
如果觉得完成工作时间不够，不要选择更长的迭代周期，因为它不会改变可用时间，只是改变检查进度的频率。若工作完成有困难，可缩短迭代长度（至少为一周），并按比例减少每次迭代的工作量，这有助于识别流程中的问题。
部分团队按工作日而非日历来安排迭代，如将迭代设为五个工作日，这对一周迭代有帮助，可减少假期对团队速度的影响。但不建议这样做，因为与利益相关者安排时间更困难，且XP团队有规律的节奏有助于建立信任，按工作日迭代则缺乏这种效果。
2. 松弛时间的重要性
项目计划如同连接工作站和插座的电源线，需要有一定的松弛度，否则稍有震动就可能导致断电，丢失正在进行的工作。项目计划也不能因小问题而被打乱，需要松弛时间来保障。
3. 松弛时间的确定
所需松弛时间的多少不取决于面临问题的数量，而取决于问题的随机性。若每次迭代总是遇到固定时长（如20小时）的问题，速度会自动调整；若问题时长在20 - 30
