Scrum Master的分工，核心是把“流程守护与障碍清除”从业务职责中分离出来：Product Owner决定做什么、先做哪个，开发团队决定怎么做并交付增量，Scrum Master负责协作机制是否有效、障碍是否被清除。本文围绕这三方与管理层的职责边界，给出职责表、活动交接步骤、配套交付物和完成检查清单，帮助刚担任或正在梳理该角色的读者把分工落到具体活动上。
要点总览（TL;DR）
- Scrum Master的分工核心是把流程守护与障碍清除从业务职责中分离：Product Owner决定做什么与先后顺序，开发团队决定怎么做并交付增量，Scrum Master负责协作机制与障碍清除。
- 用一张RACI职责表把关键活动的决策人、执行人、被咨询人、被知会人写清楚，同时写明哪些角色不介入，避免同一件事出现两个决策人。
- 按待办梳理、迭代计划、日常协作、评审与回顾逐项定义输入、动作、输出和完成标志，让角色交接有可核对的产出物。
- 用职责表、障碍清单、会议节奏表和改进项台账四份交付物固化分工，各自明确负责人与更新频率，避免分工停留在口头约定。
- 在迭代回顾或阶段性复盘中按检查项核对分工，重点识别Scrum Master变成项目经理、Product Owner缺位、团队被动等待三类偏差。
先划清四条职责线：谁决策、谁执行、谁支持、谁不介入
角色分工混乱，通常源于同一件事上出现了两个决策人，或者某个角色在关键活动上缺位。划清边界时，可以按四条职责线逐项确认：决策权归谁、执行由谁承担、支持由谁提供、哪些角色不介入。Scrum Master的职责定位是流程守护、障碍清除、协作引导和Scrum实践辅导，这四项都指向“让协作机制运转”，不指向业务内容本身。
Product Owner对产品价值和待办优先级负责，包括确定需求内容、排序和验收标准。开发团队对交付增量负责，包括技术方案、任务拆分和完成质量。管理层与职能经理的位置是提供资源、人员配置和组织层面的支持，为团队排除制度性障碍，不直接介入迭代内的执行安排。Scrum Master不替Product Owner排优先级，也不替团队做技术决策；这两条边界一旦模糊，Scrum Master就会滑向项目经理或技术负责人的角色。
下表用RACI方式呈现关键活动的归属。R为执行人，A为最终决策人，C为被咨询人，I为被知会人。表格可作为团队讨论的起点，具体填写需结合团队实际角色设置。
| 关键活动 | Product Owner | 开发团队 | Scrum Master | 管理层/职能经理 |
|---|---|---|---|---|
| 确定需求内容与验收标准 | A/R | C | I | I |
| 待办优先级排序 | A/R | C | C（保障流程与共识） | I |
| 迭代范围承诺 | C | A/R | C（引导会议） | I |
| 技术方案与任务拆分 | C | A/R | I | I |
| 障碍登记与推动清除 | C | R（提出障碍） | A/R（推动清除） | C（资源类障碍） |
| 组织回顾会与跟踪改进项 | C | R（参与并提出改进） | A/R（组织与跟踪） | I |
| 人员配置与资源投入 | I | I | C（反馈团队状况） | A/R |
这张表的价值在于把“谁不介入”也写清楚。例如技术方案一栏中Scrum Master只被知会，意味着他可以提问、可以提示流程影响，但不参与技术选型的表决。管理层在迭代范围一栏只被知会，意味着迭代内范围调整由团队与Product Owner处理，管理层通过阶段性沟通了解进展。
按活动落地分工：从待办梳理到迭代收尾的角色交接
职责线解决静态归属，活动交接解决动态配合。每类活动都应明确输入、动作、输出和完成标志，交接点上的产出物是判断分工是否落地的直接依据。以下按活动顺序展开，迭代执行与需求池维护的详细操作属于相邻主题，这里只说明角色交接。
待办梳理与优先级排序
输入是Product Owner维护的待办列表和来自各方的需求信息。Product Owner主导排序，向团队说明优先级依据；Scrum Master保障梳理会有固定节奏、有明确议程，并确保团队对需求的理解达成共识，但不参与排序结论。输出是经过澄清、具备验收标准的待办条目，完成标志是团队对下一阶段候选条目没有理解性异议。
迭代计划
输入是已排序的待办条目和团队产能信息。Product Owner说明需求目标与优先级，团队评估工作量并承诺迭代范围，Scrum Master引导会议流程、控制时间盒、提示团队关注承诺的合理性，但不决定范围内容。输出是迭代目标、承诺的需求清单和初步任务拆分，完成标志是团队对迭代目标形成一致理解，任务拆分到可执行粒度。
日常协作与障碍处理
输入是每日进展和团队提出的障碍。团队负责执行任务、更新工作项状态；Scrum Master在站会中推动进度与风险对齐，登记障碍并明确责任人与升级路径，跨角色沟通由他牵头协调。输出是更新后的任务状态和障碍清单，完成标志是每个障碍都有责任人、下一步动作和预期关闭时间。
评审与回顾
评审中Product Owner组织相关方确认增量是否符合预期，团队演示成果，Scrum Master保障评审按节奏进行并记录反馈去向。回顾由Scrum Master组织，团队提出改进项，Product Owner和管理层按需提供输入。输出是评审反馈和回顾改进项清单，完成标志是改进项有负责人、有完成时间，并进入跟踪。
| 活动 | 输入 | Scrum Master动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 待办梳理 | 待办列表、需求信息 | 保障节奏与议程，促成共识 | 澄清后的待办条目 | 候选条目具备验收标准 |
| 迭代计划 | 排序后的待办、产能信息 | 引导流程、控制时间盒 | 迭代目标与任务拆分 | 团队对目标一致理解 |
| 日常协作 | 每日进展、障碍 | 推动对齐、登记并升级障碍 | 任务状态、障碍清单 | 障碍有责任人与关闭时间 |
| 评审 | 迭代增量、相关方反馈 | 保障节奏、记录反馈去向 | 评审反馈记录 | 反馈明确后续处理方式 |
| 回顾 | 迭代数据、团队意见 | 组织会议、跟踪改进项 | 改进项清单 | 改进项有负责人与期限 |
角色分工的交付物与协作机制：职责表、障碍清单与会议节奏
分工停留在口头约定，通常在一个迭代内就会走形。让分工可被检验的方式，是把职责归属、障碍处理和改进跟踪固化为几份固定交付物，并明确每份交付物的负责人和更新频率。
- 角色职责表（RACI）：字段包括活动名称、决策人、执行人、被咨询人、被知会人和备注。由Scrum Master维护，迭代回顾时复核一次，角色或流程调整时即时更新。
- 障碍清单：字段包括障碍描述、提出人、责任人、影响范围、升级路径、预期关闭时间和关闭标准。由Scrum Master登记和推动，每日或每周更新，关闭标准是障碍消除且提出人确认。
- 会议节奏表：列明每类会议的组织者、参与者、时间盒和产出。Scrum Master是站会、回顾会的组织者，Product Owner是待办梳理和评审的主要组织者，节奏表本身由Scrum Master维护。
- 改进项台账：记录回顾产生的改进项、负责人、期限和状态。由Scrum Master跟踪，每次回顾会开始时先核对上一轮改进项的完成情况。
这些交付物承载的是角色之间的交接约定。当团队使用协作平台时，职责表和会议节奏可以作为文档沉淀，障碍与改进项则以工作项形式流转，状态变化本身就成为分工运转的记录。ONES 敏捷研发管理解决方案覆盖需求管理、迭代规划、进度跟踪、迭代复盘等环节，并将需求提出方、产品经理、研发、测试等角色连接在同一流程中；ONES Wiki 支持文档关联任务，也支持在文档中插入工作项列表，适合把职责表、会议节奏与对应工作项放在一处维护。障碍清单与改进项台账的具体承载方式，可按团队现有工作项类型和状态流设计，不必另建一套体系。
一个团队的分工示例：从职责表到一次迭代的交接
以下为一个演示情景，用于说明职责表如何在迭代中运转，团队规模和角色设置均为示例设定，不作为普遍事实。
示例团队设为一个产品方向下的单团队，包含一名Product Owner、一名Scrum Master、五名开发人员和一名测试人员，管理层为一名研发负责人。职责表按S1的表格填写，其中迭代范围承诺由团队决策、Scrum Master引导，障碍清除由Scrum Master推动、资源类障碍升级至研发负责人。
迭代中的三类典型交接可以这样处理：
- 优先级变更：迭代中途出现高优先级需求，Product Owner评估后决定是否替换迭代内条目，Scrum Master组织团队确认影响并记录范围变更，研发负责人只被知会。判断要点是变更决策由Product Owner做出，Scrum Master保障团队理解变更后果。
- 障碍升级：团队提出测试环境不足的障碍，Scrum Master登记后判断属于资源类问题，按升级路径提交研发负责人，明确预期关闭时间，并在站会上同步进展。判断要点是Scrum Master推动清除，资源调配的决定权在管理层。
- 回顾改进项落地：回顾提出缩短评审准备时间，团队指定负责人，Scrum Master录入台账并在下次回顾核对。判断要点是改进项由团队认领，Scrum Master跟踪而不代做。
这个示例可迁移的规律是：每个交接点都有明确的决策人和产出物，Scrum Master在其中的动作是组织、记录和推动，而非代替他人决策。适用边界在于，多团队或跨部门协作场景中，障碍升级路径和会议节奏需要按组织结构重新设计，不能直接照搬单团队设定。
分工是否真的运转：完成检查与常见偏差
分工是否有效，可以通过一组可核对的检查项来判断。建议在迭代回顾或阶段性复盘时执行，由Scrum Master组织，团队和管理层代表参与。
| 检查项 | 通过标准 | 偏差纠正动作 |
|---|---|---|
| 决策是否由对应角色做出 | 优先级由Product Owner决定，技术方案由团队决定，有记录可查 | 回溯近期决策，把被代做的决策归还原角色并说明边界 |
| 障碍是否有责任人与关闭标准 | 清单中每项障碍都有责任人和预期关闭时间 | 补全字段，明确升级路径，站会同步 |
| 交接是否有明确产出 | 计划、评审、回顾均有对应产出物 | 为缺失产出的活动补充模板和负责人 |
| 改进项是否被跟踪 | 上轮改进项有完成状态记录 | 回顾会固定核对环节，未完成项说明原因 |
常见偏差有三类。第一类是Scrum Master变成项目经理，表现为替团队分配任务、催进度、对外承诺交付时间；识别信号是团队在站会上只向Scrum Master汇报，纠正动作是把任务分配权交回团队，Scrum Master聚焦流程与障碍。第二类是Product Owner缺位，由Scrum Master代管优先级；识别信号是待办排序长期由Scrum Master完成，纠正动作是明确Product Owner的决策责任，Scrum Master只保障梳理流程。第三类是团队被动等待安排；识别信号是迭代计划中团队不提出范围异议，纠正动作是在计划会中要求团队给出评估依据，并让团队认领改进项。
检查的阻断项包括：关键活动连续两个迭代无明确决策人、障碍清单长期无更新、回顾改进项连续未闭环。出现任一阻断项时，应先修复对应机制再继续推进其他改进，避免分工问题被新的流程动作掩盖。
常见问题
团队规模很小、没有专职Scrum Master时，这套分工还能用吗？
可以用，但需要把角色兼任的边界写进职责表。小团队中常见的情况是Scrum Master由开发人员或产品人员兼任，此时要在职责表中明确：在哪些活动上他以Scrum Master身份引导流程，在哪些活动上他以团队成员身份参与决策。例如迭代计划会上，他作为团队成员可以评估工作量，作为引导者则负责控制时间盒和促成共识，两种身份的动作要分开记录。
兼任的风险在于障碍清除容易被日常开发任务挤占。建议为障碍清单设定固定的检查时点，并在回顾会上核对障碍的关闭情况，用机制弥补精力分散。
Product Owner长期缺位，Scrum Master临时接手优先级排序是否可行？
作为短期过渡可以，但需要明确这是临时安排并设定结束条件。Scrum Master代管优先级会削弱Product Owner的决策责任，时间一长团队就默认排序由Scrum Master负责，分工边界随之失效。
更稳妥的做法是：由管理层指定一名有决策权的代理人，Scrum Master只保障梳理流程和共识达成；同时在障碍清单中把“Product Owner缺位”登记为组织类障碍，明确责任人和解决期限。回顾会上应持续跟踪这一项，直到决策责任回到对应角色。
多个团队共用一名Scrum Master时，会议节奏和障碍升级路径要怎么调整？
多团队场景下，单团队的会议节奏表不能直接照搬。需要先明确哪些会议按团队分别召开、哪些需要跨团队对齐，再为每类会议指定组织者，避免同一时段冲突。障碍升级路径也要按组织结构重新设计：团队内可解决的障碍由各团队自行处理，涉及共享资源或跨团队依赖的障碍，需要指定统一的汇总入口和升级责任人。
Scrum Master在这种结构下的动作重心从单团队引导转向跨团队协调，职责表中应补充跨团队障碍的登记与推动条目，并明确与管理层的沟通频率。
职责表建好之后，怎么判断它是在真正起作用，还是只挂在文档里？
看决策记录和产出物，而不是看表格是否完整。可核对的信号包括：近期的优先级调整能否追溯到Product Owner的决策；迭代计划会上团队是否提出过范围异议并给出评估依据；障碍清单中的条目是否有责任人和关闭时间，并且确实被关闭；回顾改进项在下一轮回顾时是否有完成状态。
如果这些记录长期缺失或由同一人包办，说明分工没有真正运转。此时应先修复对应机制，再推进其他流程改进。
管理层希望每周了解迭代进展，这与“管理层不介入迭代内执行”是否冲突？
不冲突，关键在于区分知会与决策。管理层定期了解进展属于知会范畴，可以通过固定节奏的进展同步或数据报表实现；迭代内的范围调整、任务分配和技术方案仍由Product Owner与团队处理。
落地时可在职责表中把管理层的角色标注为被知会人，并约定同步的频率和内容口径，例如进度、风险和需要管理层支持的资源类障碍。这样既满足管理层的知情需求，也避免日常执行被频繁打断。
