Scrum会议怎么开？四个会议事件与待办事项细化的分工

Scrum 会议不是把同一份进度轮流汇报五遍。计划会决定这一轮为什么做、做哪些事；每日站会调整近期协作；评审关注产品结果；回顾关注团队的工作方式。产品待办事项细化则贯穿开发过程，为后续选择工作做好准备。

先澄清一个容易混淆的数量：依据 《Scrum Guide 2020》，Sprint 是包含其他事件的事件，内部有计划、每日 Scrum、评审和回顾四个正式事件；待办事项细化是持续活动，不是第五场规定会议。下面仍逐一说明这五类常见协作活动，但不把它们误称为五种正式 Scrum 会议。

把不同活动的输入和结果放在同一张 项目看板上，可以帮助团队在会前核对事实、会后追踪决定。白板承担记录和协作的作用，不能替团队决定优先级，也不能仅凭把卡片拖到“已完成”就证明工作已达到质量要求。

1. 敏捷管理要解决什么问题

当用户反馈和实现条件还在变化时，一次性把所有细节定死容易积累错误假设。迭代的价值在于缩短检查间隔：先交付有边界的结果，观察它是否解决问题，再调整下一步。敏捷并不等于不要文档、随时插单，或要求成员用更多会议证明自己很忙。

以“预约用户能够自行改期”为例，团队需要共同明确：哪些预约允许改期、可以选择哪些时段、改期失败怎么处理。如果这些问题还没讨论清楚，反复问“开发完成多少”并不能减少返工。不同会议应分别处理范围、协作、结果和方法，而不是把所有疑问集中到一次站会里。

2. Scrum 与看板：会议节奏和工作状态不是一回事

Scrum 是一种组织复杂产品工作的框架，看板则可以用于呈现工作如何流动。不能把“Scrum”和“看板方法”写成 Scrum 框架下面的两个类型，也不能把画出三列卡片等同于完整实施 Scrum。

使用上面的模板时，可以把“预约改期”放在一条故事行，拆出规则确认、时段查询、提交改期和结果检查等工作。若测试正在等待可用时段数据，应把依赖写在阻碍区，并指向需要协助的人，而不是让卡片长时间停在“测试”列却不说明原因。

三列看板适合先把任务状态说明白。工作复杂后，可以依据真实交接增加“待评审”“待验证”等状态，但每个状态都要有进入和离开的条件。例如，“已完成”不应只表示代码写完，还应与团队采用的完成定义一致。状态名称越多不代表管理越精细，没人使用或含义重叠的列反而增加误解。

3. 四个会议事件与待办事项细化分别怎么做

活动	要回答的问题	会后应留下什么
Sprint 计划	这一轮为什么有价值，选什么工作，怎样推进	目标、选入的事项及实现计划
每日 Scrum	距离目标的近期协作需要怎样调整	可行动的近期计划与需要继续解决的阻碍
Sprint 评审	这一轮产品结果和新反馈意味着什么	共同理解及后续产品方向的调整
Sprint 回顾	工作方法中有什么值得保留或改变	能落实的改进
产品待办事项细化	未来工作还有哪些边界不清	更明确、更小、便于讨论的事项

（1）Sprint 计划：不是整个项目的启动会

计划会面向接下来这一个 Sprint，而不是一次性确定整个项目的全部里程碑。Scrum 团队共同参与，其中开发人员需要基于实际情况选择可承担的工作并制定实现计划，不能把产品负责人的愿望清单直接当成已确认的交付承诺。

在预约改期的例子中，会前至少准备允许改期的业务规则、用户问题和已知依赖。会上先判断当前 Sprint 目标，例如“让符合条件的用户完成一次改期并看到结果”；再讨论哪些工作是实现这个结果所必需的。批量改期、历史记录美化等相关想法可以留在待办列表，不必因为与主题相关就全部塞进当前 Sprint。

在白板上保留“目标—选入事项—依赖—暂不纳入”四个区域。讨论结束后，找一位成员沿着这四块复述计划；如果仍说不清哪种改期失败属于当前范围，应继续澄清，而不是只补一个截止日期。

（2）每日 Scrum：看目标和阻碍，不做逐人述职

每日 Scrum 是开发人员的 15 分钟事件。是否站着不是关键，也不必把固定的三问当作唯一形式。讨论要让团队知道接下来怎样协作，详细的技术排查可以由相关人员在会后继续。

“我昨天写了接口，今天继续写”很难帮助别人协作。更有用的记录是：“改期提交已能返回结果，但缺少时段冲突样本，今天需要与负责时段数据的同事一起确认。”这里包含工作状态、阻碍和下一动作。其他成员能够判断是否需要协助，主持者也能把深入讨论留给相关人员。

（3）Sprint 评审：让反馈影响下一步产品决定

评审由 Scrum 团队与关键利益相关者一起检视结果和环境变化，不应只是播放演示稿后宣布进度。准备材料时，区分已完成结果、尚未完成的工作和新发现，不能用一张静态效果图掩盖还不能使用的功能。

预约改期的评审可以围绕一次完整用户任务展开：选择符合规则的预约、查看可改时段、提交变更、确认结果。请相关人员讨论“这些条件是否覆盖实际业务”，而不只询问界面是否好看。若出现“临近开始时间也希望改期”的新需求，先记录用户与业务背景，再决定待办事项如何调整，不在会上随口保证下一轮全部完成。

（4）Sprint 回顾：讨论协作方式，不重复产品评审

评审主要看产品结果，回顾主要看工作方法。回顾并没有“必须由产品经理主持”的固定要求；团队需要营造能够讨论问题的环境，Scrum Master 负责帮助事件有效进行，而不是替所有人给出结论。

继续看改期案例：如果后期才发现时段冲突规则缺失，回顾应追踪它为何没有在前期显现。是缺少相关角色、规则没有放在共同材料中，还是评审只检查正常路径？对应改进可以是“下一次规则评审增加失败路径和业务规则确认人”，并明确由谁组织、在哪里检查；“提高责任心”则没有可执行的对象。

模板中的情绪曲线有助于回忆关键时刻，但不能代替事件证据；完成率也不能单独证明工作质量。更细的主持和行动跟进方式可参考线上迭代复盘会的三个环节。

（5）产品待办事项细化：把“大需求”变成能讨论的工作

细化可以按需要持续进行，不必等到计划会才第一次理解需求。对“支持改期”这样的宽泛事项，先写出适用对象、业务限制、主要路径和未解问题，再考虑怎样拆小。不要把一个大需求仅按“前端、后端、测试”拆成几块，就以为用户价值和验收边界已经明确。

可先区分“符合规则时提交改期”“时段已满时保持原预约并提示重选”“提交结果未知时如何查询”等情形，再与团队讨论这些工作如何组合成可用的结果。每条卡片保留关联需求和待确认问题；无法估量影响的部分先调查，不用一个看似精确的数字掩盖未知。

在 Boardmix 中，便签适合记录问题和决定，连线适合标出依赖，任务列适合呈现状态。会议结束后把行动与对应事项放在一起，下一次协作继续使用同一份材料，避免每开一次会就复制一套失去上下文的列表。