“我们应该定1周、2周还是3周？”
这是每一个刚开始实践Scrum的团队都会遇到的经典问题。翻看教科书，Scrum指南只会告诉你迭代（Sprint）周期应不超过一个月，且一旦确定应保持稳定。但这1到4周的巨大范围，却让很多团队感到迷茫。
根本不存在一个“唯一正确”的迭代长度。比初始设定更重要的，是团队将迭代长度视为一个可调整的“调节阀”，用以匹配自身独特的业务节奏和技术能力。 这篇文章，我们就从实际场景出发，聊聊如何找到并优化属于你自己的节奏。
一、 初始设置：没有最好，只有最合适的起点
在团队毫无经验时，闭着眼选一个是最快启动的方式。
推荐从2周开始：这是一个经过大量实践检验的、平衡的选择。它既有足够的时间来完成一些有价值的工作，又不至于让反馈周期过长。对于大多数团队来说，2周是一个不错的起点。为什么不是1周？：1周的迭代意味着会议频率（计划会、评审会、回顾会）很高，团队可能会感觉“总是在开会”，留给专注编码的时间偏少。为什么不是4周？：4周的反馈周期太长，如果方向有偏差，一个月后才发现，修正成本太高。
请记住，这个初始设置不是一成不变的。它只是一个用于让你“跑起来”的初始参数。
二、 迭代长度的“调节阀”思维：根据三大信号动态调整
团队运行了几个迭代后，就要开始检视迭代长度是否成为了瓶颈。出现以下信号，可能就是需要调整的时候了。
信号一：业务需求频繁“插队”，计划总被打乱
场景：迭代进行到一半，频繁出现必须立即处理的紧急需求。PO和团队为此关系紧张。诊断：这是“计划外工作”的冲击。需要判断根源：是PO规划不力，还是业务本身变化就极其频繁？调整方向：如果业务高频变化是常态，那么缩短迭代长度（如从2周改为1周）是合理选择。更短的周期意味着更短的规划视野，让团队能更灵活地接纳变化，让“插队”常态化、规律化。
信号二：迭代节奏与发布节奏错位
场景：迭代结束时产品无法发布，真正的发布点落在下个迭代中期，导致版本管理混乱。诊断：团队的“开发心跳”与“交付心跳”不一致。调整方向：将迭代长度调整为与发布周期一致。比如发布周期是3周一次，那就用3周的迭代。目标是让每个迭代结束时，都能产生一个真正可发布的增量，实现开发与交付的同步。
信号三：为了赶进度，不断降低“完成”的标准
场景：团队总是在迭代最后几天疯狂加班，或者将测试、文档等工作挪到“迭代后”完成。诊断：当前迭代长度无法容纳完成所有工作项（达到 DoD）所需的时间。调整方向：这里有两个选择：
延长迭代：如果工作项确实复杂，且无法再拆分，可考虑适当延长迭代（如从2周改为3周），但要非常谨慎，这通常是最后的选择。坚持长度，改进过程（推荐）：将“无法在迭代内完成DoD”作为一个改进项。团队可以暂时调整DoD以实事求是，但同时必须致力于技术改进（如提升自动化测试水平），最终目标是在现有迭代内达成完整的DoD。
三、 终极状态：当团队不再需要“迭代”作为交付的枷锁
以上讨论，都基于一个前提：团队需要迭代这个框架。但敏捷的终极目标，是超越框架。
随着团队工程能力的极致提升（全面自动化测试、持续集成/交付），当团队可以做到任何时刻都能安全、快速地将一个单一功能部署上线时，我们就进入了“流式开发”的状态。
在这个时候：
迭代的“交付枷锁”作用消失了：你不再需要攒一个迭代的功能再发布，而是可以按需发布，甚至一天发布多次。迭代可退化为“计划节奏”：迭代周期（如果还保留的话）仅作为团队内部同步、梳理需求和规划的未来工作的一个沟通协调节奏，而不再是交付的节拍。
这就好比从“班车”（固定时间发车）进化到了“出租车”（随时可出发）。班车模式对于初步建立秩序非常有效，而出租车模式则代表了极致的流动效率和响应能力。
总结
关于迭代周期，请记住这三个核心观点：
始于标准：若无头绪，从2周迭代开始。精于检视：将迭代长度视为可调节的变量，在回顾会议中持续检视它是否仍服务于团队和价值流动。终于流动：迭代是通向持续交付的脚手架，而不是终点。培养团队强大的内部能力，最终追求的是价值的顺畅流动，而非对固定周期的严格遵守。
推荐更多阅读内容 超越规则：让Scrum团队工作协议成为驱动高效协作的“活契约” 如何成为一名卓越的产品负责人？职责、陷阱与五大核心能力 超越流程：以领导力维度，重新定义卓越的Scrum Master 超越会议主持者：深入解读Scrum Master的三个关键维度 当团队陷入“假努力”：Scrum Master的破局之道 Scrum Master的必修课：如何将团队的“思维不同频”转化为高绩效燃料？ 组件Scrum团队：为什么稳定性是高效能的隐形基石 组件Scrum团队：跨职能协作与敏捷交付的核心密码 Scrum 与看板方法的核心区别是什么？你的项目适合哪一种？