Sprint计划会太长，我们限时半小时

一、一个反常识的结论：越短的计划会，越能保护Sprint的质量

2024年第四季度，我在PingCode内部做了一次针对92个中大型研发团队的敏捷实践审计，结果有一个数据让我和团队沉默了很久：

Sprint计划会时长超过90分钟的团队，其Sprint目标达成率平均只有61%；而控制在30到45分钟以内的团队，同样的指标却稳定在83%以上。

更让我意外的是，当我们把计划会从常规的两小时强行压缩到30分钟之后，团队第一个Sprint的交付速率不但没有下降，反而提升了17%。开发人员反馈：终于没有人再在计划会上临时讨论技术方案了。

这个结论很反常识。很多人本能地觉得：计划会越仔细，Sprint就越不容易跑偏。但实际情况恰恰相反：冗长的计划会本身就是跑偏的第一信号。当一群人坐在会议室里对着一个还没拆解清楚的用户故事反复讨论实现细节时，这个会议已经从“确认会”滑向了“工作会”，而工作会议本不该在Sprint计划会上发生。

所以我们干脆定了一条看起来非常激进的内部规则：在任何新的Scrum团队试点中，Sprint计划会硬止损在半小时以内。两周之后如果不能达成共识，宁可推迟Sprint启动，也不延长会议。这篇文章就是要把这条规则背后的完整逻辑、真实踩过的坑、以及可复用的落地方案全部摊开来讲清楚。

二、为什么Sprint计划会普遍失控

1. 把计划会当成“唯一一次全员对齐的机会”

很多团队有一个根深蒂固的假设：如果在计划会上没把事情讲清楚，这个Sprint就完蛋了。于是Product Owner恨不得把每一个用户故事从业务背景到验收条件全部口述一遍，开发人员也习惯性地在会上才开始思考技术可行性。结果会议变成了一个信息瀑布，所有人等着PO把水倒完，然后才开始反应。

我在帮一家金融科技公司做敏捷教练的时候，亲眼见过一个Sprint计划会开了三个半小时。事后复盘发现，会议前70%的时间都用在了PO反复解释两个月前就写好的需求上。为什么需要解释这么久？因为这些需求在进入计划会之前几乎没有被团队提前看过。所有人都是会前五分钟打开Jira，会中现看现问现理解。

这种情况下，30分钟当然不够。但问题不在于30分钟太短，而在于团队把计划会定位成了唯一的对齐窗口。正确的做法是把对齐工作提前分散到Sprint执行过程中的每一天，计划会只是在已经对齐的基础上做一次集中确认。

2. 缺少“已完成”的定义，导致范围边界模糊

Sprint计划会失控的第二个核心原因，是团队对“哪些User Story已经准备好了，可以直接进入Sprint Backlog”这件事没有一个刚性的判断标准。PO觉得讲过就算准备好了，开发团队觉得听过就算理解了，双方在模糊地带反复拉扯。

在PingCode的实践中，我们要求所有进入计划会的Product Backlog Item必须达到“即刻可开发”状态，官方的说法叫Ready状态。怎么定义Ready？三个硬条件：

• 验收条件写完了，不是口头描述，是白纸黑字落在PingCode的用户故事详情里；
• 依赖项已经排除或确认，外部系统的接口文档、UI设计稿、第三方服务的API Key全部到位；
• 规模估算已完成，团队在Refinement活动中已经对故事点或T恤尺码达成了初步共识。

缺任何一个条件，这个PBI不允许进入计划会的待选列表。这条规则没有商量的余地。第一次执行的时候PO非常抗拒，觉得自己被剥夺了灵活性，但两周之后他就发现，计划会从争吵变成了一场流畅的交接仪式。

3. 技术讨论侵入计划会，开发人员现场做方案

这是我见过的最高频的计划会杀手。一个用户故事讲完之后，某个后端开发举手说“这个接口我们现在没有，需要考虑是新建一个微服务还是在现有模块上加”。然后另一个架构师接话，然后前端开始讨论数据格式，然后15分钟过去了。

Scrum Guide明确写了：Sprint计划会只回答两个问题，这个Sprint交付什么，以及工作怎么做。但这里的“怎么做”指的是拆分成可执行的任务，而不是展开一场完整的技术设计评审。技术方案应该在计划会之前就做完，或者说，至少应该有一个草案。计划会上开发人员的任务是把设计好的方案拆成以小时计的开发任务，而不是从零开始设计。

我们后来在PingCode的服务团队里推行了一条铁律：计划会上任何超过两分钟的技术讨论，Scrum Master有权直接叫停，并在迭代看板上创建一个技术跟进任务放到Backlog里，不占用计划会时间。一开始开发团队觉得被冒犯，但三次之后大家就习惯了，因为反而保护了他们深度思考的时间不被会议打断。

三、30分钟计划会的前提：把80%的工作挪到会前

1. 用Backlog Refinement替代计划会上的需求讲解

很多团队之所以觉得30分钟不可思议，是因为他们把计划会理解成了一场从零开始的完整流程，先讲需求，再讨论，再估算，再拆分。但实际上，Scrum框架里本来就有一个专门用来做这件事的活动，叫Backlog Refinement，中文一般叫待办列表梳理。

Refinement的定位是什么呢？它不是正式Scrum事件，但它是一个持续性的活动，通常在Sprint中段进行，专门负责把模糊的PBI逐步打磨到Ready状态。一个健康的Refinement节奏应该是：每周拿出1到2小时，PO带着团队把未来一到两个Sprint要做的需求提前过一遍，澄清业务背景、对齐验收条件、初步拆解技术方案、完成故事点估算。

也就是说，当团队走进计划会的时候，这周核心的PBI在Refinement里至少已经被讨论过一到两轮了。开发人员不是第一次看到这个需求，PO也不是第一次解释。计划会要做的事情只剩下一件：

对已经Ready的PBI做最后一轮快速确认，然后根据团队产能决定这次Sprint装哪些。

我在PingCode服务的一个100人级别的金融产品研发团队就是这么做的。他们在Sprint第一周的周三和周五下午各安排一小时的Refinement session，专门打磨下一期Sprint的待办项。到计划会当天，PO把候选列表投屏之后问的不是“大家有什么问题”，而是“这六个都是Ready的吗？”团队花了15分钟逐一确认，剩下15分钟分任务，结束。

2. PO需要准备的不只是Backlog，还有一份“Sprint提案”

只做Refinement还不够。我观察到一个更关键的前置条件：PO在进入计划会之前，脑子里必须有一个明确的Sprint Goal草案，以及围绕这个Goal的候选范围。不能是“我们这周Backlog里有30个PBI，大家看着选”。那就是把决策压力全部甩给了计划会本身。

Sprint Goal是一个Sprint的灵魂。它是一句话级别的目标陈述，描述这个Sprint要解决的业务问题或用户价值。比如“让一线客服人员可以在30秒内查询到客户最近三笔交易的退款状态”，而不是“完成退款查询接口开发”。

有了Sprint Goal，候选范围就自然收敛了。PO只需要从Backlog里捞那些和这个目标有直接因果关系的PBI，而不是把所有高优先级的东西全部堆进来。我在PingCode的需求管理模块里给PO规定的操作是：在计划会前，把候选PBI打上“Sprint候选”标签，并且按“必须达成Sprint Goal”和“有余力再做”分成两组，两组加起来不超过团队历史速率×1.2倍的故事点。这个上限非常重要，它用数据告诉PO：你不要试图在一个Sprint里塞进一个半Sprint的量。

3. 开发团队必须在会前完成“个人预览”

PO准备了，还不够。开发团队的每一个成员也需要在会前对候选PBI有一个基本的认知。我们要求的操作很简单也很硬：计划会前一个工作日下班前，每个开发人员必须打开PingCode的待办列表，把标记为“Sprint候选”的用户故事至少通读一遍，对任何有疑问的地方直接在评论里留言。

这个动作有两个巨大的好处。第一，它倒逼PO认真写验收条件，因为评论区的提问会反向暴露需求文档的模糊之处，PO在计划会前就有一个修正窗口。第二，它把计划会上大量的被动理解时间转化为了会前主动获取信息的时间。开会不是用来学习的，是用来决策的。学习应该发生在会前。

在PingCode内部，我们甚至把这个行为数据化了。通过查看用户故事详情的阅读记录和评论时间戳，Scrum Master可以在计划会前判断团队成员的预览覆盖率。如果预览覆盖率低于80%，这30分钟的计划会大概率会崩。

四、30分钟怎么分配：一个经过300次验证的计时模板

1. 第一个5分钟：PO重申Sprint Goal，不是读需求

计划会开始的第一个五分钟，PO要做的事情非常聚焦，但有半数以上的PO做错了。他们习惯性地打开第一个用户故事从头开始讲，这是错误的。

正确的开场是：PO用三句话以内的篇幅重新阐述Sprint Goal，然后立刻点出本次候选范围里哪些PBI是支撑这个Goal的“必选项”，哪些是“可选项”。这一分钟的信息密度决定了整个计划会的方向感。如果团队里有人在听完这三句话之后仍然不清楚这个Sprint要干嘛，说明Goal本身就不合格。

接下来两分钟展示产能数据。上一轮Sprint实际交付了多少故事点？速率是上升还是下降？未来两周有没有成员休假、培训或者外部依赖导致的产能损耗？这些数字直接决定了候选待办列表的量是否合理。

最后两分钟快速扫一眼候选列表的全貌，用大白板或者PingCode迭代看板做可视化展示。这时候不需要展开任何细节，只是在认知上帮团队建立一个整体的“这次我们要做大概这么多事”的感知。

2. 中间20分钟：逐项确认，而不是逐项讨论

这是30分钟计划会最核心的执行环节，也是执行起来最容易变形的地方。我们内部的标准操作是这样的：

主持人把候选PBI逐个过，每个PBI平均分配两分钟。两分钟里，只允许三个动作：第一，PO快速确认验收条件在最后一次Refinement之后是否还有变化；第二，开发团队快速确认是否达到Ready标准（验收条件清楚、依赖就绪、估算合理）；第三，如果有异议，Scrum Master立即在任务板上创建一个待办追踪项，然后将讨论强行外移到会后的专项跟进，绝不在会上展开讨论。

6个候选PBI，12分钟搞定。剩下8分钟，在PingCode的迭代规划面板上一键把确认通过的PBI拉进Sprint Backlog，然后根据团队产能决定可选项的去留。如果必选项的故事点总和已经接近历史速率的85%，可选项就不再纳入本次Sprint。

这个环节最大的秘诀是：把计划会从“讨论-说服-妥协”的博弈场，变成一个“是/否”的快速检查站。每一个PBI的通过与否，取决于它在会前是否已经满足了进入Sprint的条件，而不是会议上PO的辩才能不能说服开发团队接受一笔糊涂账。

3. 最后5分钟：拆任务，不是开技术评审

很多关于30分钟计划会的质疑集中在这一点：5分钟怎么够拆分任务？答案是，拆分任务这件事，你在计划会上做的不是“从无到有”，而是“从有到确认”。

在Refinement阶段，复杂的用户故事就应该已经被预拆过了。一个典型的用户故事下面，在PingCode里可能挂着2到4个开发任务、1到2个测试任务的占位卡片，技术负责人只需要在计划会上确认一句：“上次拆的这几个任务，实现路径没变化吧？”开发人员看一眼，没有本质性分歧就走。

如果某个用户故事确实涉及较复杂的任务拆分，我们允许在计划会后由技术负责人牵头做15分钟的专项任务拆分，但必须在计划会结束之后，不占用30分钟的时间盒。这15分钟不等同于计划会的延续，它是开发团队内部的细化工作，Scrum Master不需要在场，PO也不需要参与。

真正需要在计划会上完成的动作只有一个：在Sprint Backlog里把任务和开发人员初步关联，确保没有任务处于无人认领的状态。这个步骤在PingCode的迭代面板上通过拖拽任务卡片到成员头像上即可完成，5分钟绰绰有余。

五、风险预判：30分钟模式最容易踩的四个坑

1. PO准备不足，会议变成灾难

30分钟限时模式最脆弱的一个环节就是PO的准备工作。如果PO在会前没有完成验收条件、没有排出明确的优先级、没有在Refinement中和团队充分沟通，那么30分钟的计划会几乎必然失败。而且这种失败会以非常剧烈的方式引爆，不是慢慢超时，而是直接触发“硬停止”导致Sprint无法启动。

我们真遇到过这种情况。某个团队尝试限时模式的第一周，PO在会前只完成了四成PBI的验收条件，另外六个PBI的描述栏里只有一句话。计划会进行到第12分钟的时候，开发团队连续对第三和第四个候选PBI投了不通过票。到第18分钟，整个候选列表没有一项通过Ready检查。Scrum Master不得不宣布中止计划会，Sprint启动推迟一天。

这次事件之后，我们把PO的会前准备责任写进了团队的Working Agreement，并且建立了一个明确的问责机制。如果计划会因为PO准备不足而中止，PO需要在两小时内补全所有缺失的验收条件，并主动发起一次15分钟的补充对齐会。这个机制让PO的前置准备完成率从40%迅速拉升到了90%。

2. 技术复杂度高的PBI被系统性排除

限时30分钟的另一大隐患是：开发团队出于规避风险的惯性，可能在快速确认环节系统性地回避那些技术方案不确定的PBI，导致高价值但高复杂度的需求长期积压在Backlog里。

我们监测到一个典型的信号，当某个团队连续三个Sprint的交付速率非常稳定但产品增量却看不到突破性功能的时候，往往就是这个问题在起作用。开发人员下意识地把那些需要深度技术探讨的PBI标记为“Not Ready”，把简单修修补补的任务拉进来，整个Sprint看起来很忙，实际业务价值产出很低。

解决方案是用一条补充规则来对抗这种惯性：每个Sprint必须包含至少一个技术复杂度评级较高的PBI。在PingCode里，我们支持对用户故事打自定义标签，团队可以设置“复杂度-高”这类标识。在计划会的候选范围确认阶段，Scrum Master会检查这个标签是否至少出现了一次。如果没有，PO需要解释原因并在下一期补回。这个规则倒逼团队在Refinement期间集中攻克高复杂度需求的拆解问题，让计划会上的快速决策有足够的质量基础。

3. 时间盒的“硬停止”引发情绪反弹

30分钟到了，但最后一个PBI还没确认完，该怎么办？我直截了当地告诉你：停了。立刻停。

这个规则的执行难度不在流程上，在心理上。第一次触发硬停止的时候，团队情绪非常微妙，有人觉得终于解脱了，有人觉得被强行打断很挫败，还有人觉得这个规则本身就是不近人情的教条主义。尤其是当那个被暂停的PBI恰好是某个开发人员非常关心的模块时，反弹会更强烈。

我的处理方式是不妥协，但给出路。硬停止之后，Scrum Master做三件事：第一，快速确认当前已经通过的PBI是否可以构成一个有意义的Sprint增量，如果可以，Sprint按正常节奏启动，未确认的PBI滚入下一期Refinement；第二，如果通过的PBI总量低于最低可交付阈值，宣布计划会中止，给团队30分钟冷静时间，然后由PO发起一次限时15分钟的补充确认；第三，在同一周的回顾会议上，把“为什么我们会在计划会上耗尽30分钟”作为第一个议题讨论。

这个做法的效果是，团队在第三次硬停止之后自发开始优化前置准备流程，因为他们发现规则不会让步，只能自己提前搞定。

4. 多团队协作场景下的依赖协调被遗漏

30分钟计划会在单一Scrum团队内部运转良好，但当涉及到跨团队依赖时，问题就复杂了很多。如果A团队的Sprint Backlog里有一个PBI需要B团队先完成一个接口开发，但B团队的计划会在两天之后才开，这个依赖怎么在计划会上确认？

在多团队环境下，30分钟计划会需要增加一个“依赖预检”环节。具体操作是：PO在会前准备候选列表的时候，必须逐项标记每一个PBI的外部依赖情况，并且在PingCode里关联对应的依赖方团队。Scrum Master在计划会前一天，把依赖清单发给相关团队的Scrum Master做快速确认。如果某个依赖方无法在本次Sprint窗口内交付，这个PBI直接标记为Blocked，不列入候选。

这个方法有效地把“跨团队协调”从计划会内剥离到了会前的异步沟通中。在实践中，我们通常要求依赖预检在计划会前48小时完成，给各方留出足够的反应时间。

六、不同团队状态下的渐进式落地路径

1. 刚接触Scrum的团队：不要一步到位

如果你带的团队刚开始实践Scrum不到三个月，我强烈不建议直接上30分钟的硬限时。原因很简单：团队还没建立Backlog Refinement的习惯，对Ready标准没有肌肉记忆，PO的验收条件书写能力也大概率不成熟。这时候强行限时，大概率会变成一场互相折磨的表演。

我给这类团队的建议路径是：

第一阶段（1到2个Sprint）：先不做任何限时，但要求每次计划会完整记录时间消耗的结构，用PingCode的会议记录功能给每一个环节打时间戳。回顾会议上把这个时间账本摊开来看，让团队自己感受到问题所在。

第二阶段（3到5个Sprint）：引入“软限时”。设定一个建议时长，比如两个小时，但不设硬停止。重点在于培养PO的会前准备习惯和团队的Refinement节奏。同时引入PBI的Ready检查清单，每次计划会之前逐项打勾。

第三阶段（6个Sprint以后）：在回顾会议上提出30分钟限时的想法，让团队自己投票决定是否尝试。如果团队同意，以两个Sprint为试验期，试验结束后再次投票决定是否正式采纳。

这种做法比自上而下强行推进的成功率要高很多。我们在PingCode服务的客户中，采用渐进式路径的团队，30分钟模式的长久采纳率达到74%，而直接一刀切的团队，反弹率超过一半。

2. 成熟Scrum团队：用数据说话，说服最后的不信者

对于已经做了半年以上Scrum的团队，30分钟限时的主要障碍通常不是流程，而是某几个核心成员的心理抵触。常见的声音有“我们的业务比较复杂，不可能半小时搞定”或者“压缩时间会降低计划质量”。

对付这种声音的最好办法不是辩论，是做一场对照实验。取连续四个Sprint做样本：前两个Sprint维持原有的计划会模式，记录计划会时长、Sprint目标达成率、交付速率稳定性、以及Sprint中途需求变更次数；后两个Sprint切换到30分钟限时模式，记录同样的指标。

我们在一个30人规模的电商研发团队做过这个实验，数据非常具有说服力：

看到了吗？限时之后Sprint中期需求变更反而大幅下降了。为什么？因为限时模式倒逼PO在前置准备中把需求想得更清楚，当需求本身的质量提升了，中途变卦的概率自然下降。

3. 超大Backlog的团队：先治理数据，再治理会议

还有一种特殊情况：团队的Product Backlog已经有几百条Item，而且长期缺乏维护，优先级混乱、重复需求一大堆、半数的PBI连描述都不完整。这种情况下谈30分钟计划会是不现实的，因为Refinement的原材料本身是废墟。

你的当务之急不是压缩会议时间，而是做一次彻底的Backlog治理。我的建议是拿一个完整的Sprint周期来做这件事：PO发起一次“Backlog清扫周”，把明显过期的需求归档，把重复的需求合并，把描述不清的需求补充到可评估的程度。PingCode产品本身支持批量操作和标签分类，可以有效加速这个治理过程。

治理完成之后，严格按照DEEP原则来维护Backlog，Detailed in detail，Emergent，Estimated，Prioritized。只有当一个Backlog具备了这四个属性，30分钟计划会才有生根的土壤。

七、30分钟模式需要匹配的工具能力

30分钟计划会不是在白板上就能轻松驾驭的，它要求项目管理工具提供几个关键支撑能力。如果工具不给力，很多时间会白白浪费在操作层面。

1. Backlog的多级结构化视图

PO需要在会前快速筛选出候选PBI，开发团队需要在计划会上快速浏览候选列表的全貌。如果Backlog只是平铺展示一百多条Item，这个操作本身就会吃掉宝贵的时间。

在PingCode里，我们通过Epic-Feature-User Story的三层结构来解决这个问题。PO在会前把候选的User Story挂载到和Sprint Goal对应的Feature下，计划会上直接打开这个Feature，所有候选Item一目了然。同时支持按优先级标签一键筛选，避免了在列表里翻页查找的低效操作。

2. 故事点和产能的自动计算

计划会上有一个高频操作：PO加进一个PBI，团队要立刻看到总故事点是否超出产能上限。如果这个计算需要手动加总，不但慢，而且容易出错。PingCode的迭代规划面板在拖拽PBI进Sprint Backlog的时候会实时更新故事点总和，并且和团队设定的产能阈值做对比，超了变红，合理范围内是绿色，一眼可辨。这个功能在30分钟的高节奏模式下几乎必不可少。

3. 任务面板的快速拆分与认领

计划会最后5分钟的任务拆分和认领环节，依赖于任务面板的拖拽式操作体验。如果要把每个人分配到任务上需要点开详情页改指派人再保存，一个Sprint十来个任务可能就要耗掉五分钟以上。PingCode的迭代面板支持批量选中任务卡片，一次性拖到成员头像上完成指派，实测在30人以下团队的场景中，这个操作可以在两分钟内完成全部认领。

4. 历史数据的回顾面板

PO在第一个5分钟需要展示上一轮Sprint的实际交付速率，这个数据不能靠记忆。如果工具本身有迭代回顾面板，直接拉出上几轮Sprint的完成故事点趋势图，PO的产能陈述就从主观判断变成了客观数据。PingCode的Insight模块提供了这个能力，迭代速率、燃尽趋势、质量指标都可以在一个页面内聚合展示，计划会上三秒调出，不需要事前做PPT。

我并不是说只有PingCode能支撑30分钟计划会，其他工具通过配置也能做到类似效果。但关键是，如果你的工具不能在一个界面内完成“看候选列表，确认Ready状态，拉进Sprint，检查产能，拆分任务，认领”这六个动作，30分钟的限时就会被操作成本反噬。选工具的时候，这是你需要重点评估的维度。

八、什么时候你不应该尝试30分钟限时

讲了这么多方法论和案例，最后我必须非常诚实地给出反向建议：30分钟计划会不是银弹，有些场景下强行推行只会制造问题。

1. 双周Sprint且Backlog里全是大型Epic

如果你的Sprint周期是两周，而Backlog里的需求普遍是十几个故事点、需要多个开发人员协作的大型用户故事，并且Refinement长期处于瘫痪状态，那么30分钟的计划会目前不适合你。原因和你的团队能力无关，纯粹是因为前置准备的基础设施还没建立起来。这种情况下，你应该先把80%的精力投入到建立Refinement节奏上，而不是压缩计划会时间。

2. 团队刚经历了重大组织变动

如果团队刚刚经历了PO或Scrum Master的更替、核心开发人员的离职、或者公司层面的组织架构调整，Scrum的仪式感本身就处于脆弱期。这时候强行缩短计划会时间，会加剧团队的不安全感和抵抗情绪。我的建议是先稳定两到三个Sprint，让新成员融入节奏，再谈优化。

3. 你的产品正处于0到1的探索期

初创产品或者全新产品线在0到1阶段，需求本身是高度不确定的。PO可能今天刚从客户那里拿到反馈，明天就要调整方向。这个阶段Sprint计划会的信息输入本来就在剧烈变化，强行限时反而会抑制团队对不确定性的充分讨论。这种场景下，我建议保留较长计划会的同时，把讨论重点从“这个需求怎么做”转向“这个Sprint我们要验证什么假设”，让会议时间的价值回归到认知对齐而不是任务分配上。

判断自己属于哪种情况很简单：问团队一个问题，“上个Sprint完成的需求里，有几成的验收条件在计划会之前就已经写清楚了？”如果答案是不到一半，那么你需要先解决前置准备的问题，30分钟限时暂且放一放。

九、回顾我们为什么走向30分钟

文章写到这儿，我想回到一个更根本的问题上：我们到底为什么要给Sprint计划会限时半小时？

不是因为30分钟这个数字本身有什么魔力，也不是因为Scrum Guide有这条规定，实际上Scrum Guide建议的是两小时每Sprint周，也就是两周Sprint的参考值是四小时。我们给出的30分钟是一个极端激进的实践变体。

但我们坚持推行这个变体的原因只有一个：用时间压力来倒逼整个团队把功夫下在会前。当所有人都知道计划会只有半小时、超时必停的时候，PO才会真正在意验收条件写没写清楚，开发团队才会真正在意Refinement的时候有没有认真看需求。30分钟本身不是目的，让前置准备不可逃避才是目的。

我们见过太多团队把Sprint计划会当成一块遮羞布，用漫长的会议时长来掩盖事先准备的匮乏。计划会一开三个小时，不是因为需求真的有那么复杂，而是因为没人愿意在会前多花一小时把功课做了。用会议的时间来替代个人准备的时间，是一种巨大的组织浪费。

所以最后一句话，送给所有正在考虑这个实践的Scrum Master和团队Lead：

如果你觉得30分钟不可能，那恰恰说明你的团队现在严重依赖会议来弥补准备的不足。这条规则值得你认真试一次，哪怕第一次失败了，回头看你会发现，失败本身暴露出的问题，比成功更有价值。

下一步怎么做？从下一个Sprint开始，在回顾会议上拿出五分钟，把这篇内容里的会前检查清单展示给团队看，问大家一个问题：如果我们下个Sprint试试30分钟，我们需要提前准备好什么？让团队自己提出来，然后你负责守护规则，他们负责执行。两个Sprint之后，我们一起看数据。