评估Scrum Master是否称职，需要把“团队结果”和“SM个人作用”分开看，围绕交付节奏、流程健康、障碍清除、事件质量与团队自组织程度建立一组指标，并为每个指标写明公式、分母和时间窗。本文给出五类核心指标、可复算的口径、从取数到形成判断的步骤，以及一个季度的演算示例，帮助你把零散观察变成可讨论的评估结论。
要点总览（TL;DR）
- 评估Scrum Master称职与否，应围绕交付节奏、流程健康、障碍清除、团队成长与事件质量五类指标组合判断，单个指标不能作为结论。
- 每个指标需事先固定公式、分母、时间窗与缺失值规则；分母为零或未记录时标注为数据缺失，不按零值处理。
- 评估以季度为周期、取多期趋势，结合访谈与观察证据，区分SM可影响范围与需求变更、依赖团队、人员变动等外部因素。
- 指标反映现象而非因果，常见误读包括用迭代完成率排名SM、把障碍数量多视为工作不到位；结论应落到下一周期的改进动作与观察点。
评估目标：称职判断要回答什么
评估的目的，是判断Scrum Master在流程引导、障碍清除和团队成长上是否产生了实际作用，而不是给团队的整体交付结果找一个负责人。SM的工作大多通过他人体现：站会是否聚焦、障碍是否被推动解决、回顾会的改进项是否落地、团队遇到冲突时能否自己处理。这些动作做得好，团队的节奏和协作质量通常会改善，但改善的幅度还受需求、人员、依赖关系影响。
因此评估前要先划两条线。第一条是对象线：把SM个人可影响的范围（事件组织与引导、障碍跟进、改进项推动、Scrum规则维护、团队辅导）与团队整体结果（交付量、质量、业务价值）区分开。第二条是时间线：以多期趋势作为判断基础，单次迭代的波动只作为观察线索，不作为称职与否的结论。评估结论建议写成“在哪些方面表现稳定、在哪些方面需要继续观察”，并附上支撑证据。
还需要明确一个前提：评估结论的用途是改进而非排名。若评估结果直接挂钩奖惩，团队在访谈和回顾中提供的信息会趋于保守，指标也容易被“做漂亮”。把评估定位为发展性反馈，数据质量和判断准确性都会更高。
指标与范围：五类核心指标及适用边界
五类指标分别回答不同问题，组合使用才能覆盖SM的主要职责。下表列出每类指标衡量的侧面、典型指标与使用边界。
| 指标类别 | 衡量的侧面 | 典型指标 | 适用边界 |
|---|---|---|---|
| 交付节奏 | 团队是否形成可预期的迭代节奏 | 迭代目标完成率、承诺与交付偏差、迭代内范围变更次数 | 需求波动大或团队重组期慎用；不单独用于评价SM |
| 流程健康 | Scrum事件与待办梳理是否稳定运行 | 各类事件按期召开率、事件平均时长、待办梳理频率、待办就绪率 | 远程或跨时区团队需单独说明参与方式 |
| 障碍清除 | SM是否推动障碍被识别和解决 | 登记障碍数、平均清除时长、超期未清除障碍数 | 依赖组织外部审批的障碍需标注责任方 |
| 团队成长 | 团队自组织程度与改进落地情况 | 回顾会改进项落地率、团队自主决策事项比例、SM介入频次变化 | 新团队前几个迭代以观察为主，不急于下结论 |
| 事件质量 | 关键会议是否产生有效产出 | 站会平均时长与议题聚焦度、回顾会产出行动项数量、评审会反馈闭环率 | 质量判断需结合观察记录，不能只看时长 |
这些指标适用于人员相对稳定、已运行至少三到四个迭代的团队，并且需要多期对比才有解释力。团队重组、关键成员长期缺位或业务方向大幅调整的时期，历史数据与当期数据不可直接比较，应单独标注并降低权重。指标数量不宜过多，每类保留一到两个能稳定取数的指标即可，其余作为访谈中的追问方向。
数据口径：每个指标的公式、分母与时间窗
口径不清是指标评估最常见的失效原因。同一句“迭代完成率”，按故事点算和按工作项数量算会得出不同结果；分母取承诺范围还是最终范围，结论也会相反。评估开始前应把每个指标的公式、分母、时间窗和缺失值规则固定下来，并在多期评估中保持一致。
| 指标 | 公式 | 分母与时间窗 | 缺失值处理 |
|---|---|---|---|
| 迭代目标完成率 | 按期完成的承诺工作项数 ÷ 迭代开始时承诺的工作项数 × 100% | 分母为迭代计划会上确认的范围；以单个迭代为窗口，按季度汇总 | 迭代未按计划启动时，该迭代不纳入统计并注明原因 |
| 承诺与交付偏差 | （实际交付工作量 − 承诺工作量）÷ 承诺工作量 × 100% | 工作量单位需统一（故事点或人日），全季度使用同一单位 | 工作量未估算的工作项排除，并记录排除数量 |
| 事件按期召开率 | 按期召开的事件次数 ÷ 应召开的事件次数 × 100% | 按事件类型分别统计；窗口为季度 | 因法定假期取消的事件从分母中剔除 |
| 待办就绪率 | 进入迭代时已达到就绪标准的待办项数 ÷ 迭代承诺项数 × 100% | 就绪标准需事先定义；按迭代统计 | 未做就绪判断的项计为未就绪，并标注数据缺失 |
| 障碍平均清除时长 | 已清除障碍的总清除时长 ÷ 已清除障碍数 | 单位为人日；从登记时间到关闭时间；窗口为季度 | 未关闭障碍不计入分子分母，单独列为在途障碍 |
| 超期未清除障碍数 | 超过约定时限仍未关闭的障碍数量 | 时限按团队约定（如五个工作日）；季度末快照 | 无登记记录时标注为数据缺失，不按零处理 |
| 改进项落地率 | 已完成的回顾会行动项数 ÷ 回顾会产生的行动项总数 × 100% | 按季度统计，跨季度行动项计入完成所在季度 | 未指定负责人或截止时间的行动项计为未落地 |
分母为零的情况要单独约定。例如某季度没有登记任何障碍，障碍平均清除时长没有分母，此时应写“本季度无已清除障碍记录”，而不是写0人日，更不能据此判断障碍清除做得好。数据缺失与真实的零值含义完全不同，前者说明记录机制不健全，后者说明确实没有发生。
不可比情形也要在口径中写明：团队人数变化超过一定比例、季度内包含长假期、需求来源发生切换、关键依赖团队交付延迟，都会影响指标的可比性。出现这些情况时，在评估报告中单列说明，并优先看趋势方向而非绝对值。
评估步骤：从取数到形成判断
评估按固定节奏执行，建议以季度为周期，每个周期重复同样的步骤，保证结果可比较。
- 确定周期与基线。选定评估季度，并取此前两到三个季度的数据作为基线。没有历史数据时，第一个季度只建立基线，不形成称职结论。
- 按口径取数并计算。依照上一节的定义逐项计算，每项标注数据来源、统计范围和缺失情况。计算过程保留原始记录，便于复核。
- 收集定性证据。与团队成员、产品负责人分别访谈，重点了解事件引导质量、SM在障碍处理中的实际推动、团队遇到问题时是先自行处理还是等待SM。同时查阅回顾会记录和改进项跟进情况。
- 分组形成判断。按五类指标分别写出观察：哪些指标稳定或改善，哪些指标恶化，哪些数据不足。对每个异常先排查外部因素，再讨论SM的工作方式是否相关。
- 输出结论与建议。结论分为“表现稳定”“需要观察”“需要改进”三档，每档附指标证据和访谈证据，并给出下一周期可执行的改进动作和观察点。
结论模板可以写成四段：本季度指标概览（含数据质量说明）、SM可影响范围内的表现、受外部因素影响的部分、下一周期建议关注的指标与动作。这样的结构能让评估对话聚焦在具体事实上，减少对“称不称职”的笼统争论。
评估所需的数据分散在迭代记录、事件纪要、障碍清单和改进项列表中。以ONES为例，迭代工作项与任务状态在看板和燃尽图中持续更新，站会可以围绕看板对齐进度与风险；迭代回顾可以借助燃尽图、工时日志等报表复盘进度与偏差，回顾形成的经验可通过ONES Wiki沉淀为团队知识库。系统会记录资源投入、缺陷分布、工作项滞留时间等过程数据，这些记录可以作为交付节奏与流程健康类指标的取数来源。障碍登记与改进项跟进若在工具中没有专门字段，可用工作项类型或标签建立统一记录规则，保证清除时长和落地率有稳定的分母。
例子：一个季度的评估演算
以下为演示情景，用于说明计算与解读方式，数据为虚构。某团队共8人，包含产品负责人和一名Scrum Master，季度内运行6个双周迭代，人员无变动，需求来源稳定。
障碍清除。季度内共登记障碍14个，其中11个已关闭，3个仍在处理。11个已关闭障碍的清除时长合计33人日，平均清除时长为33 ÷ 11 = 3人日。3个在途障碍中有1个已超过约定的五个工作日时限，超期未清除障碍数为1。解读时要注意：平均3人日说明多数障碍在一周内解决，但存在一个长期挂起的障碍，需要看它卡在哪个环节。若该障碍依赖外部审批，则属于SM可推动但不可单独决定的范围。
流程健康。应召开站会60次，实际召开58次，按期召开率约96.7%；两次取消均因法定假期调休，按口径应从分母中剔除，调整后为100%。待办梳理会应召开6次，实际召开5次。迭代承诺工作项共72项，进入迭代时达到就绪标准的为60项，待办就绪率为60 ÷ 72 ≈ 83.3%。这一结果说明大部分待办在进入迭代前已完成梳理，仍有约六分之一需要在下个季度改善。
团队成长。6次回顾会共产生行动项18项，季度内完成12项，改进项落地率为12 ÷ 18 ≈ 66.7%。访谈中两名成员提到，最近两个迭代中团队开始自行处理站会超时问题，SM的干预减少。这一变化与自组织程度提升的方向一致，但需要再看一到两个季度确认是否稳定。
综合判断。支持称职的证据包括：事件运行稳定、多数障碍在一周内清除、改进项有明确跟进且落地率超过一半、团队出现自主处理问题的迹象。需要继续观察的部分包括：一个超期障碍的处理路径、待办就绪率偏低是否与产品负责人协作节奏有关、改进项落地率能否在下一季度提升。这样的结论比“称职”或“不称职”的二元判断更有行动价值。
解读与限制：指标能说明什么、不能说明什么
指标反映的是一段时间内的现象，不能直接证明SM的能力，也不能建立因果关系。迭代完成率高，可能来自需求拆分更细、估算更保守，也可能来自SM改善了障碍处理；迭代完成率低，可能源于外部依赖延迟，也可能源于SM对风险的跟进不足。把单一指标的高低直接等同于SM的水平，是最常见的误读。
几种典型误读值得提前说明。其一，用迭代完成率排名SM，忽略了团队任务性质和需求稳定性的差异。其二，把事件召开率当作流程健康的全部，实际上会议开了但产出为零的情况并不少见，需要结合观察记录。其三，把障碍数量多视为SM工作不到位，障碍数量更多反映团队暴露问题的意愿，登记充分反而是好事，关键看清除时长和超期情况。其四，用改进项落地率单独评价团队成长，落地率受行动项难度和资源影响，应结合行动项内容判断。
外部因素的影响需要在解读时逐项排查：需求在迭代中途大幅变更会拉低完成率；依赖团队的交付延迟会拉长障碍清除时长；组织层面的审批流程会限制SM的推动空间；人员变动会同时影响节奏和协作质量。评估报告中把这些因素写清楚，结论才站得住。
使用建议有三条。第一，多指标交叉验证，同一结论至少有两个不同类别的指标或定性证据支撑。第二，定性证据与定量数据同等重要，访谈和观察能解释数字背后的原因。第三，定期校准口径，团队规模、工作项类型或统计工具发生变化时，重新确认公式和分母，并在报告中注明口径变更的时间点，避免跨期比较失真。做到这三点，指标评估才能成为SM改进工作的依据，而不是一次性的考核动作。
常见问题
团队刚组建或刚经历重组，还能用这套指标评估Scrum Master吗？
可以采集数据，但不宜据此下称职结论。新团队前几个迭代的节奏、协作方式和待办就绪情况都在形成中，历史基线也不存在，指标波动更多反映磨合过程。建议第一个季度只建立基线，记录事件运行、障碍登记和改进项的产生与跟进情况，同时通过访谈了解SM在引导团队建立规则上的动作。等团队运行三到四个迭代、人员相对稳定后，再引入多期对比和称职判断。
障碍登记数量少，是不是说明Scrum Master的障碍清除工作做得不好？
不能这样推断。障碍登记数量更多反映团队暴露问题的意愿和记录习惯，登记充分通常说明团队愿意把问题摆到台面上。判断障碍清除工作，应看已清除障碍的平均清除时长、超期未清除障碍数，以及这些障碍卡在哪个环节、SM推动了哪些动作。若某季度没有任何障碍记录，应标注为数据缺失并检查记录机制，而不是写成人日为零或直接给出正面评价。
指标数据不完整时，评估还能继续吗？
可以继续，但要把数据质量写进结论。做法是：对每个指标标注数据来源、统计范围和缺失情况；缺失项写“未记录”而非零值；分母为零的指标注明“本期无有效样本”，不参与趋势比较。若关键指标连续多个周期缺失，说明记录机制需要先补齐，此时评估重点放在定性证据上，例如事件引导质量、团队反馈和障碍处理的实际推动，并同步建立统一的记录规则。
评估结果要不要和Scrum Master的绩效或奖惩挂钩？
建议把评估定位为发展性反馈。指标和访谈信息一旦直接用于排名或奖惩，团队在回顾和访谈中提供的信息会趋于保守，障碍登记、改进项跟进等记录也可能被“做漂亮”，数据质量下降会直接影响判断准确性。更稳妥的做法是：评估结论用于确定下一周期的改进动作和观察点，绩效沟通另行设计，并明确哪些指标属于SM可影响范围、哪些受外部因素制约。
同一批指标在不同季度之间可以直接比较吗？
需要先确认口径和条件是否一致。团队人数明显变化、季度内包含长假期、需求来源切换、关键依赖团队交付延迟，都会影响指标可比性，出现这些情况时应在报告中单列说明，并优先看趋势方向而非绝对值。此外，工作项类型、估算单位或统计工具发生变化时，要重新确认公式和分母，并注明口径变更的时间点，避免跨期比较失真。
