定义与注意事项：

• 一个固定（定长）的时间范围，一旦开始就不允许变更（时长）
• 任务在一个时间盒内要必须完成，且只要能被完成前提，才能被承诺。
• 意味着在迭代计划阶段，只提交在时间盒中可以完成的工作。
• 时间盒的概念灌输了一种纪律性，一旦当前时间盒过期，未完成的工作将停止，并移至下一个时间盒。（实际上也要先放置到产品待办列表，根据优先级，才能确定是否下一个迭代去继续做）
• 任何不能在时间盒内完成的事情（基于团队的能力）将不得不等到下一次迭代或时间盒

• 在任何情况下，时间盒都不能延长。这意味着，不能因为客户、PO、团队或者其他干系人，提出希望在本次迭代完成所有任务，而为此延长时间盒，这是不被允许的

  时间盒例子：

• XP 迭代：2周

• Scrum 迭代/冲刺：2~4周
• 冲刺规划会：8小时
• 每日站会：15分钟
• 冲刺评审会：最长4小时
• 冲刺回顾会：最长3小时

• XP 自动化构建：10分钟

  时间盒优势：

• “反正一次迭代只提供这些时间，不能再多，也不能少”

• 保持交付的紧迫感和连续性，这样团队排除干扰，专注任务
• 敏捷项目会遇到需求不稳定和不确定的复杂情况。进行计划、开发、测试、评审和回顾的时间框迭代为团队带来了一些非常需要的操作节奏。迭代结束时的实时反馈机制确保了团队在当前迭代结束后不会偏离轨道，并且在发生变更时的航向修正不会延迟。这也是一种降低风险的技术。时间盒使风险从客户价值上转移到技术难度上
• 因为时间盒时间比较短，这样能在短期让团队进行交付后反思，从而获得调整效率的机会，持续改进流程和产品
• 避免帕金森定律的影响：工作往往会膨胀，直到填满所有可用的时间来完成它。例如，如果对系统设计估计了一个月，那么团队很可能会把整整一个月都花在相同的活动上，而不管所有的活动是增值的还是需要的。在这个过程中，它甚至可能最终使任务复杂化。通过给团队2~4周的短迭代，敏捷方法确保团队有足够的时间来完成承诺的故事。
• 避免**学生综合症**的影响：简称：拖延症，就像一个学生只有在截止日期临近时，才开始为了考试而准备复习，给自己带来了很多压力。通过坚持在短时间内迭代交付，敏捷团队保持了节奏，并专注于最后期限（即实现Sprint目标），这永远不会超过2~4周。

关于Scrum的时间盒