敏捷开发不要迷信Sprint

一、Sprint不是信仰，而是一个需要被审视的管理工具

2018年，我带的一个团队在Sprint Review上演示了一个完全没人用的功能。产品负责人面色铁青，开发团队垂头丧气，Scrum Master试图打圆场说“至少我们按时交付了”。那一刻我意识到：我们不是在敏捷，我们只是在完成Sprint。

这个功能在Sprint Planning时被定为P0优先级，产品负责人信誓旦旦地说客户急需。2周后交付，客户看了一眼说“这不是我们想要的”。问题是，客户在Sprint第二天就给产品负责人发了邮件说明需求变更，但邮件被淹没了，因为“Sprint一旦开始，需求不能改”。

这不是孤例。过去7年我参与了11个声称“实施Scrum”的团队诊断，其中有8个团队的核心问题不是“Scrum做得不够好”，而是“Scrum做得太教条以至于忘记了敏捷本身”。Sprint，这个Scrum框架中最核心的时间盒机制，正在成为阻碍真正敏捷的最大障碍。

这篇文章不会教你Scrum的3355（3个角色、3个工件、5个事件、5个价值观），不会复述Scrum Guide的内容，也不会推荐某款工具如何帮你“完美执行Sprint”。我要讲的是：什么时候你应该放下Sprint的执念，以及放下之后该怎么做。

二、Sprint机制的三个核心假设，以及它们为什么经常不成立

Sprint作为Scrum的核心机制，建立在三个关键假设之上。理解这些假设，是理解“为什么Sprint经常失效”的起点。

1. 假设一：需求可以在一个Sprint周期内保持稳定

Scrum Guide明确要求“Sprint Goal一旦确定就不能改变，Sprint Backlog在Sprint期间应保持稳定”。这个假设的来源是传统软件开发中“变更成本高”的痛点，如果开发到一半需求变了，前面的工作就白费了。

但现实是，在大量业务场景中，需求不仅会变，而且变化本身就是价值。我服务的某电商客户，业务部门在双11大促前2周发现竞品推出新玩法，需要紧急调整促销引擎逻辑。按照Scrum教条，这个需求必须等到下一个Sprint。但市场不会等你2周，竞品玩法已经上线3天，用户心智被抢占。

这个团队最终做了“违规操作”：暂停当前Sprint，重新规划。事后Scrum Master很焦虑地问我“这样还算Scrum吗”。我的回答是：“如果为了‘做Scrum’而丢掉市场机会，那不叫敏捷，叫自杀。”

判断一个需求变化是否应该在Sprint内响应，核心不是看它“是否符合Scrum规则”，而是看不响应的代价是否大于中断Sprint的代价。我总结了一个简单的判断公式：

需求紧急度 × 影响范围广度 × 不做导致的损失 > 中断Sprint导致的团队上下文切换成本

当不等式左边显著大于右边时，中断Sprint不是违规，是负责任。

2. 假设二：团队有能力在一个Sprint内完整交付一个可用增量

Scrum要求每个Sprint结束时产出一个“完成”（Done）的产品增量。这里的“完成”意味着真正可用，代码写完、测试通过、文档齐全、可以上线。

但这要求团队具备跨职能的端到端交付能力。如果一个团队的前端、后端、测试、运维是分离的，或者部分能力依赖于外部团队，那么“在一个Sprint内完成一个完整功能”就是天方夜谭。

以PingCode服务的某中型金融科技公司（200人研发团队）为例。该团队最初推行Scrum时，Sprint长度设定为2周。但很快发现，由于合规审核流程必须走独立的安审团队，一个需求从开发完成到通过安审平均需要5个工作日。这意味着Sprint结束时交付的“增量”实际上是“未通过安审的半成品”。

团队陷入两难：要么把“完成”的定义降级（Done不包含安审通过），要么接受每个Sprint都是“名义上完成实际上未完成”。这两种做法都会腐蚀Sprint机制的公信力，当“Done”不再代表真正的可用，Sprint Review就变成了“看未完成功能演示”的走过场。

这种情况下，强行维持2周Sprint只会让团队不断产生“积压的半成品”。PingCode的实践是：将安审流程可视化并前置。在Sprint Planning阶段，就把合规要求以Checklist形式挂载到用户故事上，开发过程中持续自检，而不是等到最后才抛给安审团队。但这仍然不能解决根本问题，当关键链路依赖外部团队时，Sprint的时间盒本身就是不切实际的。

3. 假设三：频繁的固定节奏交付能持续产生价值

Scrum推崇“小步快跑”，通过频繁交付获取反馈、持续调整。这个逻辑在产品探索期和成长期是成立的。但当产品进入成熟期或维护期时，“每两周交付一次”的固定节奏反而变成负担。

我观察过一个SaaS产品的维护团队，产品已经上线4年，功能稳定，客户需求以修复和小优化为主。团队仍然维持2周Sprint，结果出现两种浪费：

第一，Sprint Planning时无内容可规划。Backlog里只有3个小优化和2个Bug，却要开2小时规划会，拆任务、估算故事点，估算一个半天能做完的优化用2个故事点还是3个故事点，有意义吗？

第二，为了“填满Sprint”而制造虚假需求。产品负责人为了不让Sprint显得空，从Roadmap里拉了一些低优先级功能进来。团队做了，上线了，没人用。这是最典型的“Sprint驱动开发”而非“价值驱动开发”。

对于维护型产品，更好的节奏是Kanban式的持续流，有需求就做，做完就发布，不凑数、不等周期。但很多团队不敢放弃Sprint，因为“领导觉得没有Sprint就不是敏捷”。这是组织认知问题，不是方法论问题。

三、Sprint教条主义的四种典型表现与诊断

在多个团队的诊断中，我总结了Sprint教条主义最常见的四种表现。如果你所在团队有其中两条以上，就需要警惕了。

1. 仪式压倒实质：Sprint事件变成必须完成的KPI

典型症状：Daily Standup变成每人对着Jira念一遍昨天做了什么；Sprint Review每次都是“功能演示秀”而极少获得有价值的反馈；Sprint Retrospective产出的Action Items连续3个Sprint都是同一批。

一个信号可以帮你判断：取消某个Sprint事件，团队会觉得“轻松了”还是“少了什么”？

我让一个团队尝试取消Sprint Review的“全员演示”环节，改为异步录屏+定向邀请利益相关者观看。结果产品负责人的反馈质量反而提升了，因为看录屏的人可以跳过不关心的部分，只看和自己相关的功能，反馈更聚焦。

这个实验说明：Sprint事件的价值不在“执行了没有”，而在“信息是否有效流动”。如果一个会议无法促进信息流动，取消它不是违反Scrum，是优化Scrum。

2. 估算变成表演：故事点估算耗费大量时间但预测准确度极低

Planning Poker是Sprint Planning中的经典环节，团队成员通过出牌的方式估算用户故事的故事点。初衷是好的：让不同角色的人都能参与估算，避免单一视角的偏差。

但我在5个团队中追踪了估算故事点与实际耗时的对比数据，结果令人沮丧：

偏差率均超过±35%，但Planning耗时普遍占Sprint总容量的4%以上。把10个工作日的4%-5%用来做一个准确度不足65%的估算，ROI值得商榷。

我更倾向于Dan North（BDD提出者）的观点：与其花时间估算，不如把需求拆得更小，让每个需求本身的“大小”就足够小到可以快速完成。如果一个用户故事可以在1天内完成，估算它到底是3点还是5点还有什么意义？

3. Sprint结束时的“伪完成”：Done的定义被持续降级

这是Sprint教条主义最具破坏性的后果。因为Sprint要求每个周期产出一个“Done”的增量，当团队持续达不到时，最常见的应对不是调整Sprint长度或放弃Sprint，而是偷偷降低Done的标准。

我见过Done的定义从“已上线并验证”逐步降级为“已提测”、“代码已合并”、“已开发完成自测通过”甚至“已评审”。当Done不再意味着“用户可用”，Sprint Review的演示就变成了一场“看未上线功能秀”，产品负责人和利益相关者对Review的信任崩塌，反馈质量进一步下降，恶性循环形成。

诊断信号：问团队“Done的定义是什么”，如果不同角色给出不同答案，说明Done的定义已经失去共识。

4. 速率崇拜：把Velocity当成团队绩效指标

Velocity（速率）本来是Scrum团队用来预测“未来几个Sprint能完成多少工作”的计划工具。但很多组织把它异化为绩效考核指标，Velocity高的团队是好团队，Velocity下降就是团队不行。

这种异化导致两种扭曲行为：故事点通胀（同样规模的需求越估越高）和质量妥协（为了保持Velocity不下降而压缩测试和重构时间）。

Velocity是一个团队内部计划工具，不能横向比较，不能被管理层用来考核。一旦Velocity与管理者的关注挂钩，它的预测价值就会迅速归零，因为团队会优化“如何让Velocity数字好看”而不是“如何交付更多价值”。

四、什么时候你应该弱化或放弃Sprint

基于前面的分析，我给出一个决策框架，帮助判断当前Sprint机制是否应该被弱化或替代。注意，我不是让你“永远不做Sprint”，而是让你有意识地选择，而不是默认遵循。

1. 判断矩阵：四个维度评估Sprint的适用性

使用方式：在四个维度中，如果有两个或以上维度属于“不适用”，就应该考虑弱化Sprint机制，采用更灵活的模式。

2. 四种替代模式与选择指南

（1）Kanban持续流

适用场景：需求零散、紧急度不均衡、团队处理的是“来一个做一个”型的工作（如维护团队、运营支持团队）。

核心机制：用WIP（Work In Progress）限制管理流动，而不是用时间盒管理节奏。关注Lead Time（从需求提出到交付的时间）和Throughput（吞吐量）。

关键区别：Kanban不要求固定迭代周期，不要求Sprint Planning，不要求估算。它假设需求应该在Ready时立即开始，完成后立即交付。

（2）事件驱动发布

适用场景：产品探索期，方向高度不确定，需求变化频繁且变化本身是学习过程的一部分。

核心机制：不以时间盒为发布节奏，而是以验证假设为发布节奏。每个发布围绕一个待验证的假设进行，验证完成后立即决策下一步方向。

关键区别：Sprint假设“每2周应该发布一次”，事件驱动假设“有值得验证的东西时才发布”。后者避免了“为了填满Sprint而做低价值功能”。

（3）混合模式：Sprint + Kanban（Scrumban）

适用场景：产品有一定成熟度但仍需频繁应对紧急需求，或团队希望保留Sprint的节奏感但不想被严格锁定。

核心机制：保留Sprint的Planning、Review、Retro等事件，但允许Sprint内拉入紧急需求（前提是从Sprint Backlog中移除等量工作），或使用Buffer Sprint（在Sprint中预留一定比例的容量给未规划需求）。

以PingCode服务的一个大型制造企业研发团队为例，他们采用了“Sprint + 15% Buffer”模式。2周Sprint中，预留15%的团队容量给“Sprint期间出现的高优需求”。如果没出现，这15%用于技术债清理和自动化改进；如果出现，则从Buffer中消耗而不影响已规划的工作。运行6个月后，紧急需求响应时间从平均7天缩短到1.5天，而Sprint承诺完成率从68%提升到91%。

（4）发布火车（Release Train）

适用场景：大规模产品，多团队协作，有强依赖关系，需要统一发布节奏（如大型SaaS平台、操作系统级产品）。

核心机制：设定一个固定的发布周期（如每季度），所有团队向这个周期对齐。内部各团队可以有自己的Sprint节奏，但最终集成到统一的发布上。

关键区别：Sprint关注“单个团队的交付节奏”，Release Train关注“多团队集成的发布节奏”。后者对Sprint的要求更灵活，团队Sprint可以在此框架内动态调整。

五、放下Sprint执念并不意味着放弃纪律

每次我建议团队弱化Sprint时，最常听到的反对意见是：“如果不按Sprint来，团队会不会回到混乱状态？开发会不会被业务随时打断？”

这个担心合理，但混淆了“Sprint”和“纪律”。Sprint只是实现纪律的一种手段，不是纪律本身。放弃Sprint不等同于放弃透明度、反馈循环和持续改进。

1. 无论用不用Sprint，这三件事不能丢

（1）可视化工作流

不管用Sprint Board还是Kanban Board，团队的工作必须对所有人可见。每个需求的当前状态、阻塞点、负责人，必须在看板上一目了然。

不用Sprint后，看板管理的重点从“Sprint内的任务追踪”变为“端到端流动效率”。关注指标从Velocity变为Lead Time分布和WIP Aging（一项工作在看板某列停留多久）。

（2）限制在制品数量

这是Scrum和Kanban的公约数。Scrum通过Sprint Backlog限制在制品（一个Sprint只能装这么多），Kanban通过WIP Limit限制在制品（每列最多同时进行N项工作）。

无论用什么模式，必须明确限制团队同时进行的工作数量。没有限制，团队一定会陷入上下文切换的泥潭。一个简单规则：团队每人同时进行的工作不应超过1.5项（1项主任务+可能协助别人的0.5项）。

（3）定期回顾与改进

Sprint Retrospective的价值在于“定期停下来看看怎么做得更好”。不用Sprint，这项活动仍然需要保留，但频率和形式可以调整。对于Kanban团队，可以改为“每两周一次运营回顾会”，回顾内容不限于“上个Sprint”，而是看流动数据、阻塞模式、质量趋势。

2. 建立“无Sprint时代”的反馈循环

没有Sprint的时间盒，反馈从哪里来？我推荐三个异步反馈机制替代Sprint Review的部分功能：

（1）功能发布即通知：每个功能上线后，自动通知相关利益相关者，附上功能说明和操作录屏。谁感兴趣谁看，不强制全员参加。

（2）用户行为仪表盘：每个功能上线后72小时内，自动收集使用数据（UV、PV、转化率、报错率），数据自己说话。

（3）月度价值评审会：每月一次，回顾这个月交付了哪些功能，哪些达到了预期效果，哪些没有，为什么，下一步怎么调整。这是战略级别的回顾，而不是“看了录像然后散会”。

六、真实案例：一个主动放弃Sprint的团队

2023年，我参与了一个SaaS分析平台团队的转型过程。这个团队14人，做了2年Scrum，Sprint长度2周。

1. 转型前的状态

团队面临三个核心问题：

• 需求锁定期内变化频繁：客户是数据分析师群体，需求高度依赖他们分析场景的变化。Sprint Planning后3天内常出现需求调整，但团队坚持“Sprint不能改”。结果每个Sprint交付的功能有30%左右与客户最新需求脱节。
• Sprint Review流于形式：每次Review演示2小时，参与的利益相关者越来越少，从最初10+人降到3-4人，且多是沉默旁观。
• Velocity被管理层盯上：CTO开始比较各团队Velocity，暗示“为什么你们团队只做了这么点”。团队出现故事点通胀，同样的功能，年初估3点，年底变成5点。

Scrum Master尝试了很多“标准解法”：培训产品负责人写好用户故事、优化Sprint Planning效率、在Retro推动流程改进。但核心问题始终没有解决，因为核心问题不是流程执行问题，而是Sprint机制本身不适应这个团队的场景。

2. 转型决策：从Sprint到Kanban+Feature Flow

2023年Q3，团队做了一个大胆决定：主动放弃Sprint机制，转向Kanban持续流模式，配合“Feature Flow”管理较大功能。

具体变化：

• 取消固定的Sprint Planning：改为每周一30分钟“Ready Check”，检查看板上Ready状态的卡是否足够、是否有阻塞。
• 取消Sprint Review：改为功能上线后自动通知+异步录屏+72小时数据追踪。
• 保留Retro：频率从每2周改为每3周，但内容从“讨论上个周期”变为“分析最近的数据趋势”。
• WIP Limit：每列强限制，开发列最多同时6张卡，测试列最多3张。
• Feature Flow：对于需要跨多人协作的大功能，不强制拆入时间盒，而是用一个独立的Kanban卡片追踪整体进度，卡片上标注Stage（分析中/开发中/测试中/已发布）。

3. 转型后的数据对比（6个月）

4. 转型的关键成功因素（不是每个团队都能照搬）

这个团队的转型并非没有前提条件。复盘下来，有四个关键因素支撑了这次转型：

第一，团队已有2年Scrum基础。他们不是从零开始做Kanban，角色分工、自组织能力、质量意识都是在Scrum时期建立的。如果是一个全新团队直接做Kanban，结果很可能不同。

第二，产品负责人高度投入。PO每天花30分钟维护Backlog优先级，确保Ready池始终有2-3张高价值卡。没有这个习惯，Kanban的“拉式流动”会退化为“谁催得急就做谁的”。

第三，WIP Limit被严格执行。一旦某列达到上限，任何人不能往里塞新卡。这条规则在前两周引发了几次争论，但坚持下来后成为团队共识。

第四，管理层不再看Velocity。CTO同意不看“故事点产出”，改为看Lead Time分布和客户满意度。如果管理层仍然执着于Velocity，转型大概率失败，因为Kanban模式下没有Velocity这个指标。

这个案例的核心启示不是“Kanban比Scrum好”，而是“团队应该选择匹配自身场景的工作模式，而不是被模式绑架”。如果团队场景更适合Scrum，那就用好它。但如果Sprint已经成为瓶颈，主动放弃不可耻。

七、当你的组织不允许放弃Sprint时，怎么办

现实地说，很多团队的Scrum并非自主选择，而是公司统一要求。CTO拍板“全公司都做Scrum”，各团队照章执行。你作为Scrum Master或Tech Lead，即使认同本文观点，也未必能推动Sprint机制的改变。

这种情况下的策略不是“对抗制度”，而是“在制度框架内做有意义的优化”。以下是几个实践证明有效的做法：

1. 缩短Sprint长度而不是放弃Sprint

如果2周Sprint太长导致需求稳定假设不成立，缩短到1周。1周Sprint的Planning负担大幅降低（通常30分钟以内），需求变化的影响范围也缩小。虽然仍然有Sprint的壳，但灵活性接近Kanban。

代价：Review和Retro频率翻倍，会议成本增加。可以用“Review简化+Retro保留但缩短”来对冲。

2. 引入Sprint内Buffer

在Sprint Planning时明确预留20%的容量给“Sprint期间可能出现的紧急需求”。对内叫作“Buffer”，对外叫作“弹性容量”。这20%不规划具体任务，如果没出现紧急需求就用于技术改进。

3. 弱化故事点估算，强化需求拆分

如果公司要求必须有故事点，那就快速估（不超过5分钟一张卡），把精力放在把需求拆成“1天以内能完成”的小粒度上。当所有卡都在1天以内时，点数本身的准确度就不那么重要了，快速的交付节奏本身就能提供真实数据。

4. 用数据说话，推动制度变化

持续记录关键数据：Lead Time、需求变化频率、Sprint结束时未完成的卡、技术债堆积速度。当你拿着6个月的数据找CTO说“我们的Sprint机制导致平均每个功能比Kanban团队慢4天”，比讲理论有说服力得多。

八、自测清单：你的团队是否正在“迷信Sprint”

我用以下15个问题结束这篇文章。这些问题来自我在多个团队诊断中使用的评估工具。快速扫一遍，看看你的团队中了几个。

1. 仪式与节奏

1. Sprint Planning是否经常超过2小时？
2. Daily Standup是否每次都是“轮流汇报工作”而没有真正讨论阻塞？
3. Sprint Review到场利益相关者是否持续减少？
4. Sprint Retro的Action Items是否连续3个周期重复？
5. 如果取消某Sprint事件，团队是否会感到“轻松了”而不是“少了什么”？

2. 估算与计划

1. 故事点估算是否花费了Planning 30%以上的时间？
2. 团队是否因为“必须要有点数”而对简单任务也强行估算？
3. Velocity是否被管理者用来横向比较团队绩效？
4. 是否出现了“同一个功能，年初估3点，年底估5点”的通胀？
5. Sprint结束时是否经常有30%以上的故事未完成？

3. 完成与质量

1. “Done”的定义是否在过去一年中被降级过？
2. 不同角色对于“Done”的理解是否不一致？
3. Sprint Review演示的功能是否经常是“未上线”的？
4. 团队成员是否因为“必须赶上Sprint截止”而刻意跳过重构或测试？
5. 技术债是否在持续累积而非被有计划地偿还？

评估标准：

• 0-5个“是”：团队Sprint机制运行较健康，继续保持同时关注薄弱点。
• 6-10个“是”：Sprint机制已出现明显摩擦，建议启动专项诊断，考虑引入Buffer、缩短Sprint或试点Kanban。
• 11个以上“是”：Sprint已成为团队的负担而非助力，强烈建议评估替代模式。继续教条执行只会加速团队倦怠和人才流失。

九、结语：敏捷的终点不是Scrum，而是持续性

这篇文章不是在否定Scrum或Sprint的价值。Scrum作为一个框架，帮助了无数团队从混乱走向有序。Sprint作为Scrum的心跳，给了团队节奏感、可预测性和反馈周期。

但当一个框架从“帮助我们变得更好”变成“我们即使不适也不敢改变”时，它就不再是工具，而是枷锁。

我见过太多团队在Sprint的仪式中疲惫不堪却不敢喊停，因为“别人都这么做”“领导要求这么做”“不做Sprint就不是敏捷”。这些声音的背后是一个更深层的问题：我们是不是把“遵循框架”当成了“做事正确”的替代品？

真正的敏捷精神不是忠于Scrum Guide的每一个字，而是忠于“持续交付价值”和“持续改进”的原则。如果Sprint在帮你的团队做到这两点，请继续保持。如果Sprint在阻碍你做到这两点，请有勇气改变它。

放下Sprint的执念，不是放弃纪律，而是放弃教条。拿走仪式感，留下真正有用的，让开发回归价值，回归人，回归常识。

下一步你可以做的事：

1. 用第八节的自测清单快速扫描你的团队，看看中了几个。
2. 如果得分在6分以上，在下一次Sprint Retro中增加一个议题：“我们是否需要调整Sprint机制？”听听团队的真实感受。
3. 选一个低风险的方向做实验：缩短Sprint长度、引入Buffer、或者试点一个功能用Kanban模式交付。设置明确的观察期和数据指标。
4. 3个周期后，用数据而不是信仰来做决策。